add meta-labels input

[svix-jbrown]

This adds a meta-labels input which is passed to docker/metadata-action. In fact, the workflows already expects such an input to exist, and is just passing the empty string.

This differs from the existing input.labels because it uses the template expansion on labels performed in docker/metadata-action.

Fixes#255

[crazy-max]

Thanks for looking into this.

I think the fix should go the other way. The build workflow already exposes labels and annotations inputs, and those are rendered and merged in the build preparation step. The bug was that build.yml still forwarded undefined inputs.meta-labels and inputs.meta-annotations values to docker/metadata-action, not that build needs another public labels API.

Adding meta-labels to build.yml would duplicate the label surface, and it would still leave meta-annotations in the same state. Bake is different because it doesn't expose direct labels and annotations inputs, so meta-labels and meta-annotations belong there.

I opened #257 with the corrected change. It removes the stale build pass-throughs and adds test for build using labels and bake using meta-labels.

[svix-jbrown]

Thanks for looking into this.

I think the fix should go the other way. The build workflow already exposes labels and annotations inputs, and those are rendered and merged in the build preparation step. The bug was that build.yml still forwarded undefined inputs.meta-labels and inputs.meta-annotations values to docker/metadata-action, not that build needs another public labels API.

Adding meta-labels to build.yml would duplicate the label surface, and it would still leave meta-annotations in the same state. Bake is different because it doesn't expose direct labels and annotations inputs, so meta-labels and meta-annotations belong there.

I opened #257 with the corrected change. It removes the stale build pass-throughs and adds test for build using labels and bake using meta-labels.

does labels end up going through the same handlebars templating that meta-labels does, though? My hope was to make using this action exactly the same as using docker/metadata-action directly.

[crazy-max]

does labels end up going through the same handlebars templating that meta-labels does, though? My hope was to make using this action exactly the same as using docker/metadata-action directly.

Yes indeed, build and bake are not perfectly consistent here.

The split comes from the underlying builders. build.yml already has first-class labels and annotations inputs because docker/build-push-action has first-class labels and annotations inputs. bake.yml doesn't expose equivalent top-level workflow inputs, so it uses meta-labels and meta-annotations through the metadata-action-generated Bake definition.

So I don't think adding only meta-labels to build.yml is the right fix, because it creates two label inputs with overlapping behavior and still leaves annotations inconsistent. #257 fixes the immediate bug by removing the undefined inputs and keeping the existing build API intact.

We can revisit the API symmetry in a follow-up, where we could deprecate or remove labels and annotations from the build workflow and add meta-labels and meta-annotations instead, so build and bake expose the same metadata inputs.

[svix-jbrown]

does labels end up going through the same handlebars templating that meta-labels does, though? My hope was to make using this action exactly the same as using docker/metadata-action directly.

Yes indeed, build and bake are not perfectly consistent here.

The split comes from the underlying builders. build.yml already has first-class labels and annotations inputs because docker/build-push-action has first-class labels and annotations inputs. bake.yml doesn't expose equivalent top-level workflow inputs, so it uses meta-labels and meta-annotations through the metadata-action-generated Bake definition.

So I don't think adding only meta-labels to build.yml is the right fix, because it creates two label inputs with overlapping behavior and still leaves annotations inconsistent. #257 fixes the immediate bug by removing the undefined inputs and keeping the existing build API intact.

We can revisit the API symmetry in a follow-up, where we could deprecate or remove labels and annotations from the build workflow and add meta-labels and meta-annotations instead, so build and bake expose the same metadata inputs.

That doesn't leave any current way for anyone to apply labels whose configuration relies on the handlebars interpolation by metadata-action, though.

[crazy-max]

That doesn't leave any current way for anyone to apply labels whose configuration relies on the handlebars interpolation by metadata-action, though.

Yes as said in previous comment this will be done as follow-up:

We can revisit the API symmetry in a follow-up, where we could deprecate or remove labels and annotations from the build workflow and add meta-labels and meta-annotations instead, so build and bake expose the same metadata inputs.