-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add docker publish workflow #238
Conversation
Requesting review from @Jeffrey-Luszcz |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this @jonathanmorley ! I had a need for exactly this workflow tonight and started working on it in #240 before I saw that you'd opened this one. We should probably combine forces on them, because I like that you're building a matrix of architectures but would really like to have version-numbered containers. WDYT?
run: | | ||
mkdir -p /tmp/digests | ||
digest="${{ steps.build.outputs.digest }}" | ||
touch "/tmp/digests/${digest#sha256:}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly this will push a container that has to be referenced by the same sha as the commit from which it's built, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the arch-specific images get pushed to the registry without an explicit label. The digest you see here is a way to refer to those arch-specific images. It would not be the same as the git commit SHA.
The merge action then picks up on the digests, and references them all when making the arch-independent image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its very possible that there is a more efficient way of passing information between the jobs than this
This does support version numbered containers. See https://github.com/cvent/private-mirrors/actions/runs/11014902329 where I passed in a value of 0.20.0, and it was used as the label of the container, producing https://github.com/cvent/private-mirrors/pkgs/container/private-mirrors/278597478?tag=0.20.0 As mentioned in a comment, ideally this would be attached to the release workflow to auto-publish with the right version number |
- [x] start using the ospo-reusable-workflows for auto-labeler, pr-title, release and release-image - [x] move 'fix' to patch semver, add 'feature' to minor semver, add major/minor/patch labels to semver - [x] add release-image part to release workflow - will generate a release image called privoate-mirrors in ghcr.io with release tag and latest tag - might replace #238 (digest work there can be added) Signed-off-by: jmeridth <[email protected]>
Pull Request
Proposed Changes
This adds a workflow that will publish the docker images (x86 and arm64) to ECR.
Notes:
ubuntu-22.04-medium-arm64
runner, which is non-standardReadiness Checklist
Author/Contributor
npm run lint
and fix any linting issues that have been introducednpm run test
and run tests@jeffrey-luszcz
Reviewer
bug
,documentation
,enhancement
,infrastructure
,maintenance
, orbreaking