CI(docker): Add docker labels from metadata

[Dasux]

This PR addresses issue #6511.

Following the maintainer’s guidance, this updates the Docker workflow to use the outputs of docker/metadata-action not only for annotations but also for image labels.
The goal is to ensure the metadata generated by the action is fully utilized in the build-and-push step, aligning the workflow with the examples shown in the upstream docker metadata documentation.

If anything else should be added or adjusted, I’m happy to iterate further.

[echoix]

It still looks like it is adding a new workflow. Can you review your PR, try it on your fork, and let us know when we should look at it again?

[Dasux]

Thanks for pointing that out — I’ve reviewed the PR again and removed the stray workflow file.
I’ve verified the updated branch on my fork as well.
One thing I'd like to mention...

I tested this on my fork, and the workflow runs fine — but the labels: field in the build output still shows empty values.
Is this expected behavior inside forks, or am I missing something about when these metadata values actually populate?

[echoix]

Im reading about how labels should be created by the action. In case I still can't be sure, I would be comfortable to merge and try to fix after

[Dasux]

Hi,

This PR adds Docker image labels via docker/metadata-action outputs and wires them into the docker/build-push-action step.

The labels are generated correctly during CI, but they are only applied to images pushed from the main repository (not from forks), since Docker images are not published for pull requests or forked repos. This also explains why I couldn't see them on my fork earlier.

I also resolved the recent workflow conflict by merging upstream changes (build-args and image annotations) while preserving the label injection.

Could you please review the workflow changes?

[Dasux]

hi @echoix ...

just a ping..
could you please approve the workflows ... i'll verify if its working here

[echoix]

Why does this PR remove some explanation comments not directly related to the changes?

And can you tell if the permission change for attesting the artifacts is 100% needed for not failing the builds? If it isn't necessary, you could remove it here, and create a new PR concerning attestations, since anyways the attest-build-provenance should be migrated to "actions/attest"
https://github.com/actions/attest, as it is now only a wrapper in order to not stop working. We would review that part there

[Dasux]

Why does this PR remove some explanation comments not directly related to the changes?

And can you tell if the permission change for attesting the artifacts is 100% needed for not failing the builds? If it isn't necessary, you could remove it here, and create a new PR concerning attestations, since anyways the attest-build-provenance should be migrated to "actions/attest" https://github.com/actions/attest, as it is now only a wrapper in order to not stop working. We would review that part there

thanks for pointing that out... the comments were unintentionally removed while modifying the workflow... i didn't intend to change unrelated parts of the file...

i've restored the removed comments in the next commit.. so it only contains the relevant changes

regarding the attestations perms..... I added it from the examples from github actions... im not sure if they're strictly necessary here...
i have removed those in this current commit aswell
we can handle attestations separately as suggested...

[echoix]

You removed everything, not just the extraneous changes you made. Try to review your PR here against n before, then come back to us when ready.

[Dasux]

Now the diff should show only adding the labels using meta-data...

there is one more thing i noticed... some actions are currently pinned to specific commit SHAs...

• uses: docker/metadata-action@c299e40c65443455700f0fdfc63efafe5b349051 # v5.10.0
• uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83 # v6.18.0

In the official docs, these are referenced using major version tags (v6 and v7), which are newer than the old v5.10.0 and v6.18.0

for this PR i left them untouched, but do you think these should be updated in another PR??

[echoix]

Now the diff should show only adding the labels using meta-data...

there is one more thing i noticed... some actions are currently pinned to specific commit SHAs...

• uses: docker/metadata-action@c299e40c65443455700f0fdfc63efafe5b349051 # v5.10.0
• uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83 # v6.18.0

In the official docs, these are referenced using major version tags (v6 and v7), which are newer than the old v5.10.0 and v6.18.0

for this PR i left them untouched, but do you think these should be updated in another PR??

We take care of of the updates with renovate. The new major versions are like a week or so old. Many actions recently switched to the latest node LTS versions. There are reasons why we pin to specific hashes. Until recently, GitHub actions didn't have immutable releases. Pinning by hash was the only way to know you are not getting another content with the same tag label (a new tag pointing to a different commit instead).

[Dasux]

We take care of of the updates with renovate. The new major versions are like a week or so old. Many actions recently switched to the latest node LTS versions. There are reasons why we pin to specific hashes. Until recently, GitHub actions didn't have immutable releases. Pinning by hash was the only way to know you are not getting another content with the same tag label (a new tag pointing to a different commit instead).

got it--- stability matters more...

[Dasux]

Can we merge this?

[Dasux]

I think it should be the other way around?? Why are we merging main into this branch?
Correct me if I'm wrong..

[echoix]

I think it should be the other way around?? Why are we merging main into this branch? Correct me if I'm wrong..

CI wasn’t approved/ran yet, so might as well run it with fresh changes if it needed to be ran to have the required successful checks

[echoix]

One failed (macOS), so I triggered a rerun only for that