instruction: Create a Dockerfile for fundamentals
output: ```dockerfile
  FROM base AS build
  -ARG TARGETOS TARGETARCH
  +ARG TARGETOS TARGETARCH BUILD_TAGS
   ENV GOOS=$TARGETOS
   ENV GOARCH=$TARGETARCH
   RUN --mount=target=. \
   --mount=type=cache,target=/go/pkg/mod \
  - go build -o "/usr/bin/bakeme" .
  + go build -tags="${BUILD_TAGS}" -o "/usr/bin/bakeme" .
  That's all. With these changes, your docker buildx bake command now builds
  two multi-platform image variants. You can introspect the canonical build
  configuration that Bake generates using the docker buildx bake --print
  command. Running this command shows that Bake will run a default group with
  two targets with different build arguments and image tags.
  
  Show more
  {
   "group": {
   "default": {
   "targets": ["image-release", "image-debug"]
   }
   },
   "target": {
   "image-debug": {
   "attest": ["type=provenance,mode=max", "type=sbom"],
   "context": ".",
   "dockerfile": "Dockerfile",
   "args": {
   "BUILD_TAGS": "debug"
   },
   "tags": ["bakeme:dev"],
   "target": "image",
   "platforms": ["linux/amd64", "linux/arm64", "linux/riscv64"]
   },
   "image-release": {
   "attest": ["type=provenance,mode=max", "type=sbom"],
   "context": ".",
   "dockerfile": "Dockerfile",
   "args": {
   "BUILD_TAGS": "release"
   },
   "tags": ["bakeme:latest"],
   "target": "image",
   "platforms": ["linux/amd64", "linux/arm64", "linux/riscv64"]
   }
   }
  }
  Hide
  Factoring in all of the platform variants as well, this means that the build
  configuration generates 6 different images.
  
  $ docker buildx bake
  $ docker image ls --tree
  
  IMAGE ID DISK USAGE CONTENT SIZE USED
  bakeme:dev f7cb5c08beac 49.3MB 28.9MB
  ââ linux/riscv64 0eae8ba0367a 9.18MB 9.18MB
  ââ linux/arm64 56561051c49a 30MB 9.89MB
  ââ linux/amd64 e8ca65079c1f 9.8MB 9.8MB
  
  bakeme:latest 20065d2c4d22 44.4MB 25.9MB
  ââ linux/riscv64 7cc82872695f 8.21MB 8.21MB
  ââ linux/arm64 e42220c2b7a3 27.1MB 8.93MB
  ââ linux/amd64 af5b2dd64fde 8.78MB 8.78MB
  Exporting build artifactsExporting build artifacts like binaries can be useful for deploying to
  environments without Docker or Kubernetes. For example, if your programs are
  meant to be run on a user's local machine.
  TipThe techniques discussed in this section can be applied not only to build
  output like binaries, but to any type of artifacts, such as test reports.With programming languages like Go and Rust where the compiled binaries are
  usually portable, creating alternate build targets for exporting only the
  binary is trivial. All you need to do is add an empty stage in the Dockerfile
  containing nothing but the binary that you want to export.First, let's add a quick way to build a binary for your local platform and
  export it to ./build/local on the local filesystem.In the docker-bake.hcl file, create a new bin target. In this stage, set
  the output attribute to a local filesystem path. Buildx automatically detects
  that the output looks like a filepath, and exports the results to the specified
  path using the
  local exporter.
  
  target "bin" {
   target = "bin"
   output = ["build/bin"]
   platforms = ["local"]
  }Notice that this stage specifies a local platform. By default, if platforms
  is unspecified, builds target the OS and architecture of the BuildKit host. If
  you're using Docker Desktop, this often means builds target linux/amd64 or
  linux/arm64, even if your local machine is macOS or Windows, because Docker
  runs in a Linux VM. Using the local platform forces the target platform to
  match your local environment.Next, add the bin stage to the Dockerfile which copies the compiled binary
  ```