cannot parse bake definitions: ERROR: failed to find target docker-metadata-action\n```\n\n## Root cause\n\n`docker-bake.hcl`'s `bake-platform` target does `inherits = [\"docker-metadata-action\"]`. That target is defined as an empty stub (`target \"docker-metadata-action\" {}`) on every `dev-*` branch, but **not on `master`**.\n\nThe regression was triggered by [FLINK-39796] bumping `docker/bake-action` from v4 to v7. v7 changed the default of an unset `source` input: instead of baking the **local working tree**, it now falls back to the workflow's own git context and bakes it as a **remote ref**, so buildx fetches `docker-bake.hcl` (and the build context) from the triggering commit on `master`:\n\n```\ndocker buildx bake https://github.com/apache/flink-docker.git#<sha> --file .github/workflows/docker-bake.hcl ... bake-platform\n```\n\nSince the job checks out a `dev-*` branch but v7 reads `master`, two things break:\n\n1. `master`'s `docker-bake.hcl` lacks the `docker-metadata-action` stub → `inherits` fails.\n2. The snapshot Dockerfile is generated at runtime by `add-custom.sh` into the local working tree and is never committed, so a remote bake context could not find `$DOCKER_FILE` anyway.\n\nThis is why the workflow was green on v4 (which baked the local `dev-*` checkout that has both the stub and the generated Dockerfile) and red on v7.\n\n## Fix\n\nSet `source: .` on the bake step to restore the pre-v7 behavior of baking the local working tree. This resolves both issues at once: the checked-out `dev-*` tree contains both the generated Dockerfile and the `docker-metadata-action` stub.\n\n## Notes\n\n- An alternative/complementary change would be to add `target \"docker-metadata-action\" {}` to `master`'s `docker-bake.hcl` to match the `dev-*` branches. That alone is **not** sufficient under v7's remote bake, because the runtime-generated Dockerfile still wouldn't exist in the remote context — hence pinning `source: .` is the actual fix.\n",

cannot parse bake definitions: ERROR: failed to find target docker-metadata-action\n```\n\n## Root cause\n\n`docker-bake.hcl`'s `bake-platform` target does `inherits = [\"docker-metadata-action\"]`. That target is defined as an empty stub (`target \"docker-metadata-action\" {}`) on every `dev-*` branch, but **not on `master`**.\n\nThe regression was triggered by [FLINK-39796] bumping `docker/bake-action` from v4 to v7. v7 changed the default of an unset `source` input: instead of baking the **local working tree**, it now falls back to the workflow's own git context and bakes it as a **remote ref**, so buildx fetches `docker-bake.hcl` (and the build context) from the triggering commit on `master`:\n\n```\ndocker buildx bake https://github.com/apache/flink-docker.git#<sha> --file .github/workflows/docker-bake.hcl ... bake-platform\n```\n\nSince the job checks out a `dev-*` branch but v7 reads `master`, two things break:\n\n1. `master`'s `docker-bake.hcl` lacks the `docker-metadata-action` stub → `inherits` fails.\n2. The snapshot Dockerfile is generated at runtime by `add-custom.sh` into the local working tree and is never committed, so a remote bake context could not find `$DOCKER_FILE` anyway.\n\nThis is why the workflow was green on v4 (which baked the local `dev-*` checkout that has both the stub and the generated Dockerfile) and red on v7.\n\n## Fix\n\nSet `source: .` on the bake step to restore the pre-v7 behavior of baking the local working tree. This resolves both issues at once: the checked-out `dev-*` tree contains both the generated Dockerfile and the `docker-metadata-action` stub.\n\n## Notes\n\n- An alternative/complementary change would be to add `target \"docker-metadata-action\" {}` to `master`'s `docker-bake.hcl` to match the `dev-*` branches. That alone is **not** sufficient under v7's remote bake, because the runtime-generated Dockerfile still wouldn't exist in the remote context — hence pinning `source: .` is the actual fix.\n",