ci-operator: expose ephemeral cluster versions based on parents #1098
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
openshift-ci-robot
added
the
approved
When we import a release from a stream that's configured to have a name and be released in some way, we can piggy-back off of that name to create a name for our release that clearly labels us as a derivative while also uniquely identifying the test configuration that is running. All of this is best-effort and will no-op if no release config is present, allowing us to still mark the cluster version as one udner test but not identifying the parent release. Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
stevekuznetsov
force-pushed
the
skuznets/better-versions
branch
from
775c8db
to
bee450b
Compare
|
/test e2e |
|
Weird registry flake? |
JAORMX
reviewed
Aug 12, 2020
| @@ -175,6 +176,21 @@ func (s *assembleReleaseStep) run(ctx context.Context) error { | |||
| return results.ForReason("missing_release").WithError(err).Errorf("could not resolve imagestream %s: %v", streamName, err) | |||
| } | |||
|
|
|||
| // we want to expose the release payload as a CI version that looks just like | |||
| // the release versions for nightlies and CI release candidates | |||
| prefix := "0.0.1-0" | |||
There was a problem hiding this comment.
So, now the prefix would be 0.0.1-0 instead of 4. ?
There was a problem hiding this comment.
Only for the cases where we cannot determine the version, it's a fallback.
petr-muller
approved these changes
Aug 12, 2020
| @@ -175,6 +176,21 @@ func (s *assembleReleaseStep) run(ctx context.Context) error { | |||
| return results.ForReason("missing_release").WithError(err).Errorf("could not resolve imagestream %s: %v", streamName, err) | |||
| } | |||
|
|
|||
| // we want to expose the release payload as a CI version that looks just like | |||
| // the release versions for nightlies and CI release candidates | |||
| prefix := "0.0.1-0" | |||
There was a problem hiding this comment.
Only for the cases where we cannot determine the version, it's a fallback.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: petr-muller, stevekuznetsov 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 |
|
/hold e2e are broken now, holding to prevent the bot to go crazy with retests |
openshift-ci-robot
added
the
do-not-merge/hold
|
/test e2e |
openshift-ci-robot
removed
the
do-not-merge/hold
|
/retest Please review the full test history for this PR and help us cut down flakes. |
wking
added a commit
to wking/ci-tools
that referenced
this pull request
Mar 30, 2023
…e annotation bee450b (ci-operator: expose ephemeral cluster versions based on parents, 2020-08-11, openshift#1098) taught assembleReleaseStep to consume the release.openshift.io/config annotation on an ImageStream to find a version prefix that actually reflects the 4.y release branch (instead of using 0.0.1-0 as the prefix). Those annotations are set on the app.ci ImageStreams, for example: $ oc whoami -c default/api-ci-l2s4-p1-openshiftapps-com:6443/wking $ oc -n ocp get -o json imagestream 4.13 | jq -r '.metadata.annotations["release.openshift.io/config"] | fromjson | .name' 4.13.0-0.ci But they are not set in ImageStreams contained within release images: $ oc adm release info -o json registry.ci.openshift.org/ocp/release:4.13.0-0.ci-2023-03-29-224346 | jq '.references | {kind, metadata}' { "kind": "ImageStream", "metadata": { "name": "4.13.0-0.ci-2023-03-29-224346", "creationTimestamp": "2023-03-29T22:52:54Z", "annotations": { "release.openshift.io/from-image-stream": "ocp/4.13-2023-03-29-224346" } } } With this commit, I'm taking the name out of the imported release ImageStream and trying to parse it as a Semantic Version. If it parses, I'm constructing a release.openshift.io/config annotation to set just the 'name' property to the MAJOR.MINOR.SPEC from that parsed name. This should allow cluster-bot runs like: launch 4.13.0-0.ci,openshift/cluster-version-operator#918,openshift/hypershift#2318 hypershift-hosted to build releases named 4.13.0-0-... instead of their current 0.0.1-0-...: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880/artifacts/release/artifacts/release-payload-latest/image-references | jq -r .metadata.name 0.0.1-0.test-2023-03-30-043404-ci-ln-h9dwcbk-latest which is failing to run with [1]: Release image is not valid: { "lastTransitionTime": "2023-03-30T04:36:29Z", "message": "releases before 4.8 are not supported", "observedGeneration": 3, "reason": "InvalidImage", "status": "False", "type": "ValidReleaseImage" } [1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880#1:build-log.txt%3A203-210
wking
added a commit
to wking/ci-tools
that referenced
this pull request
Mar 30, 2023
…e annotation bee450b (ci-operator: expose ephemeral cluster versions based on parents, 2020-08-11, openshift#1098) taught assembleReleaseStep to consume the release.openshift.io/config annotation on an ImageStream to find a version prefix that actually reflects the 4.y release branch (instead of using 0.0.1-0 as the prefix). Those annotations are set on the app.ci ImageStreams, for example: $ oc whoami -c default/api-ci-l2s4-p1-openshiftapps-com:6443/wking $ oc -n ocp get -o json imagestream 4.13 | jq -r '.metadata.annotations["release.openshift.io/config"] | fromjson | .name' 4.13.0-0.ci But they are not set in ImageStreams contained within release images: $ oc adm release info -o json registry.ci.openshift.org/ocp/release:4.13.0-0.ci-2023-03-29-224346 | jq '.references | {kind, metadata}' { "kind": "ImageStream", "metadata": { "name": "4.13.0-0.ci-2023-03-29-224346", "creationTimestamp": "2023-03-29T22:52:54Z", "annotations": { "release.openshift.io/from-image-stream": "ocp/4.13-2023-03-29-224346" } } } With this commit, I'm taking the name out of the imported release ImageStream and trying to parse it as a Semantic Version. If it parses, I'm constructing a release.openshift.io/config annotation to set just the 'name' property to the MAJOR.MINOR.PATCH from that parsed name. This should allow cluster-bot runs like: launch 4.13.0-0.ci,openshift/cluster-version-operator#918,openshift/hypershift#2318 hypershift-hosted to build releases named 4.13.0-0-... instead of their current 0.0.1-0-...: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880/artifacts/release/artifacts/release-payload-latest/image-references | jq -r .metadata.name 0.0.1-0.test-2023-03-30-043404-ci-ln-h9dwcbk-latest which is failing to run with [1]: Release image is not valid: { "lastTransitionTime": "2023-03-30T04:36:29Z", "message": "releases before 4.8 are not supported", "observedGeneration": 3, "reason": "InvalidImage", "status": "False", "type": "ValidReleaseImage" } [1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880#1:build-log.txt%3A203-210
wking
added a commit
to wking/ci-tools
that referenced
this pull request
Mar 30, 2023
…e annotation bee450b (ci-operator: expose ephemeral cluster versions based on parents, 2020-08-11, openshift#1098) taught assembleReleaseStep to consume the release.openshift.io/config annotation on an ImageStream to find a version prefix that actually reflects the 4.y release branch (instead of using 0.0.1-0 as the prefix). Those annotations are set on the app.ci ImageStreams, for example: $ oc whoami -c default/api-ci-l2s4-p1-openshiftapps-com:6443/wking $ oc -n ocp get -o json imagestream 4.13 | jq -r '.metadata.annotations["release.openshift.io/config"] | fromjson | .name' 4.13.0-0.ci But they are not set in ImageStreams contained within release images: $ oc adm release info -o json registry.ci.openshift.org/ocp/release:4.13.0-0.ci-2023-03-29-224346 | jq '.references | {kind, metadata}' { "kind": "ImageStream", "metadata": { "name": "4.13.0-0.ci-2023-03-29-224346", "creationTimestamp": "2023-03-29T22:52:54Z", "annotations": { "release.openshift.io/from-image-stream": "ocp/4.13-2023-03-29-224346" } } } With this commit, I'm taking the name out of the imported release ImageStream and trying to parse it as a Semantic Version. If it parses, I'm constructing a release.openshift.io/config annotation to set just the 'name' property to the MAJOR.MINOR.PATCH from that parsed name. This should allow cluster-bot runs like: launch 4.13.0-0.ci,openshift/cluster-version-operator#918,openshift/hypershift#2318 hypershift-hosted to build releases named 4.13.0-0-... instead of their current 0.0.1-0-...: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880/artifacts/release/artifacts/release-payload-latest/image-references | jq -r .metadata.name 0.0.1-0.test-2023-03-30-043404-ci-ln-h9dwcbk-latest which is failing to run with [1]: Release image is not valid: { "lastTransitionTime": "2023-03-30T04:36:29Z", "message": "releases before 4.8 are not supported", "observedGeneration": 3, "reason": "InvalidImage", "status": "False", "type": "ValidReleaseImage" } [1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-hypershift-hosted/1641294936391290880#1:build-log.txt%3A203-210
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When we import a release from a stream that's configured to have a name
and be released in some way, we can piggy-back off of that name to
create a name for our release that clearly labels us as a derivative
while also uniquely identifying the test configuration that is running.
All of this is best-effort and will no-op if no release config is
present, allowing us to still mark the cluster version as one udner test
but not identifying the parent release.
Signed-off-by: Steve Kuznetsov skuznets@redhat.com
/assign @petr-muller @smarterclayton