-
Notifications
You must be signed in to change notification settings - Fork 112
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
Add commit SHA label to SHP image #776
Add commit SHA label to SHP image #776
Conversation
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.
Two questions:
- Should we tag the image instead of (or in addition to) labeling it?
- Should we annotate the image instead of labeling? There's a OCI standard annotation for the revision.
5d4d051
to
97535bb
Compare
97535bb
to
e062f96
Compare
@imjasonh so to answer your qs
We tag them today already right?
This was interesting. I realized In a nutshell, this PR will now add the label to images build via the nightly or once we ship a new release. |
Nope, we tag them as https://quay.io/repository/shipwright/shipwright-operator label-schema.org labels sgtm, when |
@imjasonh I see. In general I didnt want to interfere with the semantic versioning we have in place. If doing something like a |
I don't have a strong preference, and this is obviously an improvement over what we have today, so I think we should do it. The benefit of tagging would be in aiding debugging an issue at a given range of commits, but that's probably a small enough benefit that it's reasonable that it might not be worth the added complexity. /lgtm |
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.
/approve
Fine using our own namespace, since we plan on using annotations once ko supports it.
KO_DOCKER_REPO="$IMAGE_HOST/$IMAGE" GOFLAGS="${GO_FLAGS}" ko resolve -t "$TAG" --image-label "io.shipwright.vcs-ref=${GITHUB_SHA}" --bare --platform=all -R -f deploy/ > release.yaml | ||
KO_DOCKER_REPO="$IMAGE_HOST/$IMAGE" GOFLAGS="${GO_FLAGS} -tags=pprof_enabled" ko resolve -t "$TAG-debug" --image-label "io.shipwright.vcs-ref=${GITHUB_SHA}" --bare --platform=all -R -f deploy/ > release-debug.yaml |
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.
Just making a note that we are using a label-schema inspired label, and not label-schema itself. To do so would require using the org.label-schema
namespace and also supplying the schema-version
label.
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.
@adambkaplan good catch, indeed this is a label-schema inspired, not fully compliant with the docs there.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adambkaplan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Changes
Adding the SHA that trigger the build of https://quay.io/repository/shipwright/shipwright-operator as a label. This is mainly to have a clear mapping to the commit on this same repository.
Note: Wondering if we should use
quay.expires-after
label, for the nightly images, we can set a max lifetime for those ones, so that we keep pruning them.Submitter Checklist
See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes