test/e2e: always use correct release pull spec in RELEASE_IMAGE_LATEST#188
test/e2e: always use correct release pull spec in RELEASE_IMAGE_LATEST#188sosiouxme wants to merge 1 commit intoopenshift:masterfrom
Conversation
with 5.0 the release repo changed; ci-operator should always supply the correct one in this var.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sosiouxme The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/retest-required |
|
@sosiouxme: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
| rhel_coreos_extensions_image=$(oc adm release info registry.ci.openshift.org/ocp/release:${ocp_version} \ | ||
| rhel_coreos_extensions_image=$(oc adm release info "${RELEASE_IMAGE_LATEST}" \ | ||
| --registry-config "${CLUSTER_PROFILE_DIR}/pull-secret" \ | ||
| --image-for=rhel-coreos-extensions) |
There was a problem hiding this comment.
| --image-for=rhel-coreos-extensions) | |
| --image-for=rhel-coreos-10-extensions) |
Is probably what would work as a quick hack on 5.0. Still a hack but a bit more complete would be to check both rhel-coreos-extensions and rhel-coreos-10-extensions image and if one of those has kernel packages that match the node then assume we're good enough.
Still that's naive and will need to be updated, we don't want to accept a payload that's got rhel9 content aligned but rhel10 ouf of sync.
There was a problem hiding this comment.
main will forward to 5.0 and 4.23 until those branch, so the code probably has to handle both. perhaps there is / could be another env var to provide the coreos major version.
There was a problem hiding this comment.
Both 5.0 and 4.23 will have at least rhel-coreos-extensions and rhel-coreos-10-extensions so checking both for a match should be OK
| test_kernel_rt_version() { | ||
| ocp_version=$(oc get clusterversion -o json | jq -r '.items[0].status.desired.version') | ||
|
|
||
| rhel_coreos_extensions_image=$(oc adm release info registry.ci.openshift.org/ocp/release:${ocp_version} \ |
There was a problem hiding this comment.
note that for 5.0 the repo is release-5
There was a problem hiding this comment.
lets use the actual image, AFAIK this should always be populated.
oc get clusterversion -o json | jq -r '.items[0].status.desired.image'
quay.io/openshift-release-dev/ocp-release@sha256:9b7068aa6f6087c2f0a7cefa241c5dbb0ede0efaad783607dff0da98cac432d2
|
/hold |
openshift-ci
Bot
added
the
do-not-merge/hold
3 participants
with 5.0 the release repo changed; ci-operator should always supply the correct one in this var.