bumper: Verify new release image exist

[ormergi]

What this PR does / why we need it:
Currently when a components release is issued, it take time for the image to upload to the registry.
The result is the auto-bumper posting bump PR but the image is not available yet.

To workaround this check that the component new release image exist before posting a PR.

Extent components.yaml to contain the container image base tag.

The check assume the new image tag match the 'metadata' field.

Special notes for your reviewer:
The new check relay on the fact the new release image tag is the same as the release tag.
For example, ipam-ext release is v0.6.0-rc1, the release container image tag will be ghcr.io/kubevirt/ipam-controller:v0.6.0-rc1.

This PR may not work for Kubemacpool as expected:
Kubemacpool release tags doesnt equal to the release image tag, for example:
release tag - v0.50.0-25-g5727cd1 -
https://github.com/kubevirt/cluster-network-addons-operator/blob/main/components.yaml#L19
container image tag - v0.50.0-25-g5727cd18
https://quay.io/repository/kubevirt/kubemacpool?tab=tags&tag=%20v0.50.0-25-g5727cd18
It seems that the container tag missing containing one extra character (from the commit SHA).

Possible workaround would to address this on kubemacpool release process side.

Release note:

[kubevirt-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[kubevirt-bot]

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign ramlavi for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[maiqueb]

you have my buy-in to this.

Let's just see CI passing :)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[RamLavi]

@ormergi thank you for tackling this!

My 2cents: Skopeo is flaky sometimes, why not just check if the output images are valid?

[ormergi]

@ormergi thank you for tackling this!

My 2cents: Skopeo is flaky sometimes, why not just check if the output images are valid?

I didn't manage to implement this check using curl/wget and keep in agnostic to the target registry.

Did you mean to utilize container runtime for this?
If so using the container runtime doesnt allow inspecting remote image, it must be pulled which I tired to avoid.

Where does skopeo falls that makes it flaky? Do you think some retrying mechanism would stabilize it?

[ormergi]

The new check relay on the fact the new release image tag is the same as the release tag.
For example, ipam-ext release is v0.6.0-rc1, the release container image tag will be ghcr.io/kubevirt/ipam-controller:v0.6.0-rc1.

This PR may not work for Kubemacpool as expected:
Kubemacpool release tags doesnt equal to the release image tag, for example:
release tag - v0.50.0-25-g5727cd1 -
https://github.com/kubevirt/cluster-network-addons-operator/blob/main/components.yaml#L19
container image tag - v0.50.0-25-g5727cd18
https://quay.io/repository/kubevirt/kubemacpool?tab=tags&tag=%20v0.50.0-25-g5727cd18
It seems that the container tag missing containing one extra character (from the commit SHA).

Possible workaround would to address this on kubemacpool release process side.

I updated the PR description with this finding.

[kubevirt-bot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[RamLavi]

The new check relay on the fact the new release image tag is the same as the release tag.
For example, ipam-ext release is v0.6.0-rc1, the release container image tag will be ghcr.io/kubevirt/ipam-controller:v0.6.0-rc1.
This PR may not work for Kubemacpool as expected:
Kubemacpool release tags doesnt equal to the release image tag, for example:
release tag - v0.50.0-25-g5727cd1 -
https://github.com/kubevirt/cluster-network-addons-operator/blob/main/components.yaml#L19
container image tag - v0.50.0-25-g5727cd18
https://quay.io/repository/kubevirt/kubemacpool?tab=tags&tag=%20v0.50.0-25-g5727cd18
It seems that the container tag missing containing one extra character (from the commit SHA).
Possible workaround would to address this on kubemacpool release process side.
I updated the PR description with this finding.

Hey @ormergi thanks for this change, but the fact that some components follow latest branch commits kinda makes it harder to predict (like KMP as you mentioned).

Please consider a different approach, like checking the images vars.

$ awk -F'"' '/ImageDefault/ { img=$2; if (img ~ /[@:]$/) { print "invalid image at line " NR ": " img; bad=1 } } END { exit bad }' pkg/components/components.go
invalid image at line 45: ghcr.io/kubevirt/ipam-controller@