Add commit SHA label to SHP image

[qu1queee]

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

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

Add SHA label to SHP controller img

[imjasonh]

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.

[qu1queee]

@imjasonh so to answer your qs

Should we tag the image instead of (or in addition to) labeling it?

We tag them today already right?

Should we annotate the image instead of labeling? There's a OCI standard annotation for the revision.

This was interesting. I realized ko doesn´t support annotations today, so I will say that we cannot do it now via ko. I read image-spec/annotations and I assume your suggestion on annotation is due to them superseding labels. Because we cannot use annotations with ko I updated my label key to follow a combination of reverse domain notation + compatible prefix . Leading to io.shipwright.vcs-ref, see the description of the vcs-ref label in label-schema.org.

In a nutshell, this PR will now add the label to images build via the nightly or once we ship a new release.

[imjasonh]

Should we tag the image instead of (or in addition to) labeling it?

We tag them today already right?

Nope, we tag them as v0.4.0 and v0.4.0-debug, or nightly-2021-05-12-1620796767(-debug), but not with the commit SHA.

https://quay.io/repository/shipwright/shipwright-operator

label-schema.org labels sgtm, when ko supports annotations we should annotate the manifest too, but it's not a big deal.

[qu1queee]

Nope, we tag them as v0.4.0 and v0.4.0-debug, or nightly-2021-05-12-1620796767(-debug), but not with the commit SHA.

@imjasonh I see. In general I didnt want to interfere with the semantic versioning we have in place. If doing something like a docker inspect on an image generated by the nightly or the release CI would give me a reference to the exact commit SHA from where it was generated, then my goal was achieved. The value of adding a tag with the commit SHA is that the ref to source code is clear, and you do not need to inspect the image (from what I can see today), but I would like to avoid more images on top of what we have. Whats your thinking?

[imjasonh]

@imjasonh I see. In general I didnt want to interfere with the semantic versioning we have in place. If doing something like a docker inspect on an image generated by the nightly or the release CI would give me a reference to the exact commit SHA from where it was generated, then my goal was achieved. The value of adding a tag with the commit SHA is that the ref to source code is clear, and you do not need to inspect the image (from what I can see today), but I would like to avoid more images on top of what we have. Whats your thinking?

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

[adambkaplan]

/approve

Fine using our own namespace, since we plan on using annotations once ko supports it.

[adambkaplan]

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.

See https://label-schema.org/rc1/

[qu1queee]

@adambkaplan good catch, indeed this is a label-schema inspired, not fully compliant with the docs there.

[openshift-ci]

[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:

• OWNERS [adambkaplan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment