How to access the built image sha

[dhensby]

I'm looking at implementing docker image signing as part of our release process. To do this, ideally we'd have access to the sha of the built image. Is there any way to expose this value so that it can be used in an exec step or similar?

[esatterwhite]

@dhensby
Currently, I don't think so. I don't think its possible to pass information between stages, or at least it isn't a documented/supported feature of semantic-release.

How would you want to use this? an example would be helpful.

[dhensby]

So using something like notion you (ideally) want to get your hands on the raw image sha for signing. It's not much more than: notation sign --signature-format cose $IMAGE (where $IMAGE is image@sha:xxxx see: https://notaryproject.dev/docs/quickstart-guides/quickstart-sign-image-artifact/)

The issue is that builds don't seem to have a predictable tag nor a way to get your hand on it so you can resolve the hash locally.

Though, looking at the code - perhaps if I can set build_id, instead of it being random, the local tag will be predictable and I'll be able to find the image 🤔

[dhensby]

If there was a way to set this build_id deterministically at run time, then I'd be able to run: docker images --no-trunc --quiet "image-name:${build_id}" to get the hash

[esatterwhite]

If there was a way to set this build_id deterministically at run time, then I'd be able to run: docker images --no-trunc --quiet "image-name:${build_id}" to get the hash

Not currently, but it wouldn't be difficult to add.

Also, and I'll have to confirm, but I might just be able to mutate the nextRelease object with the docker build info. Then you could reference it other states / plugins provided they support templating of some kind

[esatterwhite]

Additionally as I'm working through it now, I'm not sure that would work if you were using buildx as the build + push happen in the same docker command and the images are not stored locally.

it may not effect you, but something to think about.

[dhensby]

The images are available locally if the clean flag is set to false, right? 🤔

[esatterwhite]

This images are available locally if the clean flag is set to false, right? 🤔

Yes.
I'm talking in a future state, if you were to start building multi-arch images w/ buildx ( a thing I'm working on now ), that would not be the case.

So nothing to worry about here, I'm just thinking out loud.

[Th3S4mur41]

Looking for something similar in order to take advantage of actions/attest-build-provenance in GitHub CI.

Right now, this seems only to be possible by publishing the docker image using docker/build-push-action after semantic-release.

[esatterwhite]

How would you expect to get access to it?

[esatterwhite]

The final image sha, or the tag of an image?

[dhensby]

The signing programs can complain if you don't give the actual image sha, so that would be idea.

[Th3S4mur41]

How would you expect to get access to it?

I'm not sure either...
In order to get the version, I extract it from the package.json and add it as an output parameter for the CI job.

echo "version=$(npm run env | grep npm_package_version | cut -d '=' -f 2)" >> $GITHUB_OUTPUT

I can then reuse the new version in any of the following jobs.
If there is any way I could access the sha of the published image, I could do something similar

[dhensby]

At the moment I use the exec provider for semantic release to add the release version as an output:

  - ['@semantic-release/exec', {
      "publishCmd": 'echo "version=${nextRelease.version}" >> "$GITHUB_OUTPUT"'
    }]

Then I use that version to do the signing with notation: ./notation sign --signature-format cose --id "$CERT_ID" --plugin azure-kv --plugin-config self_signed=true "$IMAGE"

Where $IMAGE is and env var constructed as so: dockerhost.com/image-name:${{ steps.release.outputs.version }}

---

Edit (for clarity): This causes notation to complain because it wants a sha instead - and that's what I'd like to be able to get my hands on somehow even if it means another exec call that just adds the image sha to the output.

[esatterwhite]

Ah, I see. Thanks, that helps. I think mutating the release object could work. Provided semantic release isn't re-creating it for each plugin