Description

The official documentation states that annotations cannot be overridden.

However, the code claims that only "inherits" cannot be overridden.

In practice, using --set with annotations doesn't work:

$ docker buildx bake --print
{
  "target": {
    "default": {
      "annotations": [
        "index-descriptor,manifest-descriptor,index,manifest:com.myorg.ci.tags.stable=stable"
      ],
      "context": ".",
      "dockerfile": "Dockerfile",
      "tags": [
        "tag1"
      ]
    }
  }
}

$ docker buildx bake --print \
  --set *.tags='foo' \
  --set *.annotations='index-descriptor,manifest-descriptor,index,manifest:com.myorg.ci.tags.stable=bar'
{
  "target": {
    "default": {
      "annotations": [
        "index-descriptor,manifest-descriptor,index,manifest:com.myorg.ci.tags.stable=stable"
      ],
      "context": ".",
      "dockerfile": "Dockerfile",
      "tags": [
        "foo"
      ]
    }
  }
}

But it actually works if it's included in a docker-bake.override.hcl file:

$ cat docker-bake.override.hcl
target default {
  annotations = [
    annotate("tags.stable", "bar"),
  ]
  tags = ["foo"]
}

function annotate {
  params = [key, value]
  result = "index-descriptor,manifest-descriptor,index,manifest:com.myorg.ci.${key}=${value}"
}

$ docker buildx bake --print
{
  "target": {
    "default": {
      "annotations": [
        "index-descriptor,manifest-descriptor,index,manifest:com.myorg.ci.tags.stable=stable",
        "index-descriptor,manifest-descriptor,index,manifest:com.myorg.ci.tags.stable=bar"
      ],
      "context": ".",
      "dockerfile": "Dockerfile",
      "tags": [
        "foo"
      ]
    }
  }
}

In this case, the annotations are merged together.

Is this intended, or just an oversight?

Use case

I am writing an automated release pipeline for general CI/CD use, and I'd like to store metadata on the image as a way to carry information around:

1. The user merges to main and triggers a GitHub workflow in their repository.
2. The workflow calls the automated release pipeline workflow (what I'm working on)
3. Commits are analyzed to determine the next release (semantic versioning)
4. We dynamically generate annotations (e.g.: com.myorg.ci.semantic-release=v1.2.3)
5. We dynamically generate a random build tag (e.g.: bake-12345-1) to avoid pushing latest
6. We build and push the image(s) and return the build tag(s).
7. The user can use the returned build tags to test the images they just built.
8. Once the tests are done, they launch a CLI command which is essentially myorg-cli publish <image-name-and-build-tag>
9. The command will read the annotations on the image to find out the semantic release version.
10. The command will push the tag it just read (v1.2.3) to the image.
11. The command will also update the latest and v1 and v1.2 tags to point to this image.