Bug 1993286: fix(openshift): drop z from next calculated y-stream (#2324) #166
Conversation
When determining operator compatibility, drop z and build
versions in the calculation of the next Y-stream (minor)
release of OpenShift.
e.g. If the current version is v4.9.5+build, the next Y-stream is
calculated as v4.10.0.
If a pre-release is included, drop it as well but don't increment
the minor version.
e.g. If the current version is v4.10.0-rc, the next Y-stream is
calculated as v4.10.0.
Before this change, the next Y-stream was the result of simply
iterating the cluster's minor version. When the cluster was at
a patch version greater than that specified by an operator, upgrades
would be erroneously blocked.
e.g. If the current version was v4.9.5, the next version would be
calculated as v4.10.5, which would block upgrades on operators with
max versions set to v4.10 -- or more explicitly [v4.10.0, v4.10.5) (')'
is read "exclusive").
Signed-off-by: Nick Hale <njohnhale@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 760c10d78d6f830b5aa773080847b46557c5986a
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: njhale 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 |
openshift-ci
bot
added
the
approved
|
/lgtm |
|
/retitle Bug 1993286: fix(openshift): drop z from next calculated y-stream (#2324) |
openshift-ci
bot
changed the title
openshift-ci
bot
added
the
bugzilla/severity-high
|
@njhale: This pull request references Bugzilla bug 1993286, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
Requesting review from QA contact: In response to this:
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/test-infra repository. |
openshift-ci
bot
added
the
bugzilla/valid-bug
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
2 similar comments
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
@njhale: All pull requests linked via external trackers have merged: Bugzilla bug 1993286 has been moved to the MODIFIED state. In response to this:
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/test-infra repository. |
The tag that configures the serialization of the ServiceAccount field for the Scorecard configuration incorrectly names the field "string", which results in the `serviceaccount` field being empty after unmarshalling, therefore being ignored. Update the tag to name the field `serviceaccount` Upstream-repository: api Upstream-commit: 3e95d2c8cdd80dbf68f09a7647601239904d20fd
The tag that configures the serialization of the ServiceAccount field for the Scorecard configuration incorrectly names the field "string", which results in the `serviceaccount` field being empty after unmarshalling, therefore being ignored. Update the tag to name the field `serviceaccount` Upstream-repository: api Upstream-commit: 3e95d2c8cdd80dbf68f09a7647601239904d20fd
The tag that configures the serialization of the ServiceAccount field for the Scorecard configuration incorrectly names the field "string", which results in the `serviceaccount` field being empty after unmarshalling, therefore being ignored. Update the tag to name the field `serviceaccount` Upstream-repository: api Upstream-commit: 3e95d2c8cdd80dbf68f09a7647601239904d20fd
The tag that configures the serialization of the ServiceAccount field for the Scorecard configuration incorrectly names the field "string", which results in the `serviceaccount` field being empty after unmarshalling, therefore being ignored. Update the tag to name the field `serviceaccount` Upstream-repository: api Upstream-commit: 3e95d2c8cdd80dbf68f09a7647601239904d20fd
When determining operator compatibility, drop z and build
versions in the calculation of the next Y-stream (minor)
release of OpenShift.
e.g. If the current version is v4.9.5+build, the next Y-stream is
calculated as v4.10.0.
If a pre-release is included, drop it as well but don't increment
the minor version.
e.g. If the current version is v4.10.0-rc, the next Y-stream is
calculated as v4.10.0.
Before this change, the next Y-stream was the result of simply
iterating the cluster's minor version. When the cluster was at
a patch version greater than that specified by an operator, upgrades
would be erroneously blocked.
e.g. If the current version was v4.9.5, the next version would be
calculated as v4.10.5, which would block upgrades on operators with
max versions set to v4.10 -- or more explicitly [v4.10.0, v4.10.5) (')'
is read "exclusive").
Signed-off-by: Nick Hale njohnhale@gmail.com
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 760c10d78d6f830b5aa773080847b46557c5986a