list-targets subaction

[crazy-max]

fixes #117

https://github.com/crazy-max/docker-bake-action/tree/matrix-gen#list-targets

[tonistiigi]

What's the difference of just setting the matrix value to docker buildx bake --print validate | jq .group.validate.targets ?

I think eventually we would want to do something that would auto-split based on platform for example and then merge the subimages built from matrix together into a single image. In that case, the current limited action could be confusing, or maybe it should be named differently to make the distinction clear.

[crazy-max]

What's the difference of just setting the matrix value to docker buildx bake --print validate | jq .group.validate.targets ?

This jq command does not support groups with matrix like:

{
  "group": {
    "default": {
      "targets": [
        "validate"
      ]
    },
    "lint": {
      "targets": [
        "lint-default",
        "lint-labs",
        "lint-nydus",
        "lint-yaml",
        "lint-proto"
      ]
    },
    "validate": {
      "targets": [
        "lint",
        "validate-vendor",
        "validate-doctoc",
        "validate-generated-files",
        "validate-shfmt",
        "validate-docs"
      ]
    }
  },
  ...

But jq -cr '.target | keys' would work, see moby/buildkit#4411 (comment).

I also prefer to avoid using third-party tools and shell but rely on the node runtime and GHA SDK so we can handle exceptions more easily. We can also display debug output so user can figure out how this was computed:

I think eventually we would want to do something that would auto-split based on platform for example and then merge the subimages built from matrix together into a single image. In that case, the current limited action could be confusing, or maybe it should be named differently to make the distinction clear.

Yes sounds good to handle matrix for a specific attribute so we can cover https://docs.docker.com/build/ci/github-actions/multi-platform/#with-bake use case as well.

I think matrix-targets is self-explanatory enough? For the platform case we could have a matrix-attribute subaction that would split based on the chosen attribute?:

variable "DEFAULT_TAG" {
  default = "app:local"
}

// Special target: https://github.com/docker/metadata-action#bake-definition
target "docker-metadata-action" {
  tags = ["${DEFAULT_TAG}"]
}

// Default target if none specified
group "default" {
  targets = ["image-local"]
}

target "image" {
  inherits = ["docker-metadata-action"]
}

target "image-local" {
  inherits = ["image"]
  output = ["type=docker"]
}

target "image-all" {
  inherits = ["image"]
  platforms = [
    "linux/amd64",
    "linux/arm/v6",
    "linux/arm/v7",
    "linux/arm64"
  ]
}

      -
        name: Attribute matrix
        id: matrix
        uses: docker/bake-action/subaction/matrix-attribute@v4
        with:
          target: image-all
          attribute: platforms

Or maybe you think of having a single subaction doing both?

[Nithos]

This is great, thank you.
Yes this can be done with jq but like mentioned above it would be nice to have it covered directly within the action subsystem. This way any schema changes can be handled directly and not require updates to existing scripts etc..

Long term splitting across various platforms would be fantastic, not sure how that would work yet but it would be great if you could split it across specific runners so that ARM builds can be built using the appropriate runner as this will significantly reduce the build times.

[tonistiigi]

? For the platform case we could have a matrix-attribute subaction that would split based on the chosen attribute?:

For the platforms split we would need a merge as well so it is more complicated.

Maybe list-targets is a better name. Matrix is already a Github term for how to use the value, so duplicated on the caller side and there might be other usages.

[crazy-max]

For the platforms split we would need a merge as well so it is more complicated.

Yes the platforms one is tricky. We need to save digests refs and then have another call to consume them. This should be feasible within a single action.