search

esatterwhite / semantic-release-docker

Semantic release plugin for building and pushing docker images
MIT License
43 stars 15 forks source link

How to access the built image sha #49

Open dhensby opened 9 months ago

dhensby commented 9 months ago

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 commented 8 months ago

@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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

esatterwhite commented 8 months ago

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 commented 3 months ago

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 commented 3 months ago

How would you expect to get access to it?

esatterwhite commented 3 months ago

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

dhensby commented 3 months ago

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

Th3S4mur41 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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