Push container images to GHCR #2576
Conversation
This commit updates our GitHub workflows to push container images to GHCR in addition to GCR. Assuming all goes well, we will deprecate GCR-based images in a futur release. One major change here is that this commit ships scratch images to GHCR instead of alpine-based images. Switching base images has been something we've discussed for a while now, and now seems like the right time to do it. GCR will still receive alpine images. Signed-off-by: Evan Gilman <egilman@vmware.com>
evan2645
requested review from
amartinezfayo,
APTy,
azdagron and
rturner3
as code owners
|
|
||
| echo "Pushing images tagged as $IMAGETAG..." | ||
|
|
||
| for img in spire-server spire-agent; do |
There was a problem hiding this comment.
Notably missing here is k8s-workload-registrar and oidc-discovery-provider.
The GHCR repo is namespaced under the org rather than the repo, unfortunately. This means we need to be extra careful when selecting image names ... they should clearly reflect their purpose and make sense under the larger SPIFFE scope. In my opinion, these two names do not meet that requirement.
For the k8s-workload-registrar ... we will soon have new spire-controller code being published as an image on GHCR, so I kind of feel like we should just roll with that. It is already namespaced appropriately.
For the oidc-discovery-provider.. it relies on SPIRE APIs. I'm not sure what's best ... maybe spire-oidc-provider? Or spire-oidc-discovery-provider?
For now I've left these two out.
| @echo Building $1... | ||
| $(E)$(go_path) CGO_ENABLED=0 go build $$(go_flags) -ldflags $$(go_ldflags) -o $1 $2 | ||
|
|
||
| endef | ||
| # https://7thzero.com/blog/golang-w-sqlite3-docker-scratch-image |
There was a problem hiding this comment.
I'm not sure if it still makes sense to keep this reference here or not ... it feels old but there's no year on the post
| for img in spire-server spire-agent; do | ||
| ghcrimg=ghcr.io/"$ORGNAME"/"$img":"${IMAGETAG}" | ||
| echo "Executing: docker tag $img:latest-local $ghcrimg" | ||
| docker tag "$img":latest-local "$ghcrimg" |
There was a problem hiding this comment.
Shouldn't this be tagging the scratch image?
| docker tag "$img":latest-local "$ghcrimg" | |
| docker tag "$img"-scratch:latest-local "$ghcrimg" |
There was a problem hiding this comment.
My intention was to switch the "default" image to scratch, and that's all we ship. The move to GHCR acts as the deprecation function.
Should we continue to ship both flavors? The only argument I can see is some sort of convenience or dev image, in which case it should probably be named as such (and the non-suffixed version should still be scratch)?
There was a problem hiding this comment.
My intention was to switch the "default" image to scratch, and that's all we ship. The move to GHCR acts as the deprecation function.
That's what I figured, but I didn't see any changes in the Makefile that changed way things are tagged and the images.tar.gz loaded by this step on the workflow contains the non-scratch images.
There was a problem hiding this comment.
That's what I figured, but I didn't see any changes in the Makefile that changed way things are tagged and the images.tar.gz loaded by this step on the workflow contains the non-scratch images.
Aah yes, thanks. I will fix that.
Signed-off-by: Evan Gilman <egilman@vmware.com>
Signed-off-by: Evan Gilman <egilman@vmware.com>
Signed-off-by: Evan Gilman <egilman@vmware.com>
Signed-off-by: Evan Gilman <egilman@vmware.com>
|
I updated this PR to also push One complication is that now this no longer matches the image name we build and test against, so I had to special case it in the image push script. I left a comment there to switch everything over when we deprecate GCR ... not sure if there's a better option, open to suggestions |
This commit updates our GitHub workflows to push container images to
GHCR in addition to GCR. Assuming all goes well, we will deprecate
GCR-based images in a futur release.
One major change here is that this commit ships scratch images to GHCR
instead of alpine-based images. Switching base images has been something
we've discussed for a while now, and now seems like the right time to do
it. GCR will still receive alpine images.
Signed-off-by: Evan Gilman egilman@vmware.com