Merge pull request #16305 from thaJeztah/add_syntax_directives

add syntax directives to dockerfile examples

build/building/cache/index.md

@@ -22,6 +22,7 @@ Have a look at the following example, which shows a simple Dockerfile for a
 program written in C.
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM ubuntu:latest
 
 RUN apt-get update && apt-get install -y build-essentials
@@ -86,6 +87,7 @@ Consider the following example. A Dockerfile snippet that runs a JavaScript
 build from the source files in the current directory:
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM node
 WORKDIR /app
 COPY . .          # Copy over all files in the current directory
@@ -103,6 +105,7 @@ the dependencies. Finally, copy over the project source code, which is subject
 to frequent change.
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM node
 WORKDIR /app
 COPY package.json yarn.lock .    # Copy package management files
@@ -225,6 +228,8 @@ illustrates building a simple web server that serves HTML from your `docs`
 directory in Git:
 
 ```dockerfile
+# syntax=docker/dockerfile:1
+
 # stage 1
 FROM alpine as git
 RUN apk add git

build/building/context.md

@@ -41,6 +41,7 @@ $ docker build .
 With the following Dockerfile:
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM busybox
 WORKDIR /src
 COPY foo .
@@ -64,6 +65,7 @@ files required by the `COPY` instructions, in this case `foo`.
 In some cases you may want to send the entire context:
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM busybox
 WORKDIR /src
 COPY . .

build/buildkit/configure.md

@@ -148,6 +148,8 @@ rel="noopener" class="_"} in BuildKit as an example. Feel free to include your
 own CNI configuration.
 
 ```dockerfile
+# syntax=docker/dockerfile:1
+
 ARG BUILDKIT_VERSION=v{{ site.buildkit_version }}
 ARG CNI_VERSION=v1.0.1
 

build/buildx/install.md

@@ -20,6 +20,7 @@ Here is how to install and use Buildx inside a Dockerfile through the
 [`docker/buildx-bin`](https://hub.docker.com/r/docker/buildx-bin) image:
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM docker
 COPY --from=docker/buildx-bin:latest /buildx /usr/libexec/docker/cli-plugins/docker-buildx
 RUN docker buildx version

desktop/containerd/index.md

@@ -152,6 +152,7 @@ You can also check from the browser that Nginx is running:
 Sample Dockerfile:
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM alpine
 
 ENTRYPOINT ["echo", "hello friends"]

desktop/dev-environments/set-up.md

@@ -63,6 +63,7 @@ In the yaml file, the build context `backend` specifies that that the container
 The `development` stage of the Dockerfile is defined as follows:
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM golang:1.16-alpine AS build
 WORKDIR /go/src/github.com/org/repo
 COPY . .

desktop/extensions-sdk/build/set-up/backend-extension-tutorial.md

@@ -210,6 +210,7 @@ To deploy your Go backend when installing the extension, you need first to confi
 - it starts the binary when the container starts listening on the extension socket
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM node:17.7-alpine3.14 AS client-builder
 # ... build frontend application
 

desktop/extensions-sdk/build/set-up/frontend-extension-tutorial.md

@@ -74,6 +74,7 @@ extension:
   <div id="react-dockerfile" class="tab-pane fade in active" markdown="1">
 
 ```Dockerfile
+# syntax=docker/dockerfile:1
 FROM --platform=$BUILDPLATFORM node:18.9-alpine3.15 AS client-builder
 WORKDIR /ui
 # cache packages in layer

desktop/extensions-sdk/build/set-up/minimal-frontend-extension.md

@@ -44,6 +44,7 @@ At a minimum, your Dockerfile needs:
 - The `metadata.json` file.
 
 ```Dockerfile
+# syntax=docker/dockerfile:1
 FROM scratch
 
 LABEL org.opencontainers.image.title="MinimalFrontEnd" \

desktop/extensions-sdk/extensions/multi-arch.md

@@ -71,7 +71,6 @@ The example below shows an extension that uses a binary as part of its operation
 In the `Dockerfile`, we download the binary depending on the target architecture:
 
 ```Dockerfile
-
 #syntax=docker/dockerfile:1.3-labs
 
 FROM alpine AS dl

desktop/wasm/index.md

@@ -151,6 +151,7 @@ running in a container.
    the `ENTRYPOINT`.
 
    ```dockerfile
+   # syntax=docker/dockerfile:1
    FROM scratch
    COPY --from=build /build/hello_world.wasm /hello_world.wasm
    ENTRYPOINT [ "hello_world.wasm" ]

develop/scan-images/index.md

@@ -100,6 +100,7 @@ A Docker image is built  from a Dockerfile. A Dockerfile contains a set of instr
 Building your image is a snapshot of that image, at that moment in time. When you depend on a base image without a tag, you’ll get a different base image every time you rebuild. Also, when you install packages using a package installer, rebuilding can change the image drastically. For example, a Dockerfile containing the following entries can potentially have a different binary with every rebuild.
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM ubuntu:latest
 RUN apt-get -y update && apt-get install -y python
 ```

get-started/09_image_best.md

@@ -105,6 +105,7 @@ times for your container images.
 Let's look at the Dockerfile we were using one more time...
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM node:18-alpine
 WORKDIR /app
 COPY . .
@@ -124,6 +125,7 @@ a change to the `package.json`. Make sense?
 1. Update the Dockerfile to copy in the `package.json` first, install dependencies, and then copy everything else in.
 
     ```dockerfile
+    # syntax=docker/dockerfile:1
     FROM node:18-alpine
     WORKDIR /app
     COPY package.json yarn.lock ./
@@ -219,6 +221,7 @@ that JDK isn't needed in production. Also, you might be using tools like Maven o
 Those also aren't needed in our final image. Multi-stage builds help.
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM maven AS build
 WORKDIR /app
 COPY . .
@@ -239,6 +242,7 @@ and more into static HTML, JS, and CSS. If we aren't doing server-side rendering
 for our production build. Why not ship the static resources in a static nginx container?
 
 ```dockerfile
+# syntax=docker/dockerfile:1
 FROM node:18 AS build
 WORKDIR /app
 COPY package* yarn.lock ./