Automate FBC upgrade graph flow during release workflow#1994
Conversation
MaxBab
changed the title
MaxBab
force-pushed
the
automate_fbc_upgrade_graph_flow
branch
from
4ad2a48 to
1a2a9aa
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1994 +/- ##
==========================================
- Coverage 80.41% 76.08% -4.33%
==========================================
Files 51 58 +7
Lines 2630 3145 +515
==========================================
+ Hits 2115 2393 +278
- Misses 392 613 +221
- Partials 123 139 +16
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| : "${PREVIOUS_VERSION:?"Missing PREVIOUS_VERSION variable"}" | ||
|
|
||
| # Validate PREVIOUS_VERSION is a valid semantic version | ||
| if ! validate_semantic_versioning "v${PREVIOUS_VERSION}" 2>/dev/null; then |
There was a problem hiding this comment.
Nit: Checking exit value and additional logging is not necessary, see https://github.com/MaxBab/sail-operator/blob/1a2a9aa98e0ac081c5cf78fc07254c7e7f77217f/hack/validate_semver.sh#L35
| git tag --list | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -5 >&2 | ||
|
|
||
| # In CI, this is an error | ||
| if [ "${CI:-false}" = "true" ]; then |
There was a problem hiding this comment.
Where do we specify if we run in CI or not?
There was a problem hiding this comment.
I had a logic when added that, but rethinking again, it made no sense to keep it.
Removed it.
Instead, I've slightly modified the logic here.
If the "PREVIOUS_VERSION" var is not found within the "git tag" list, the flow is aborted to prevent a release issue.
| # | ||
| PREVIOUS_VERSION ?= $(shell \ | ||
| MAJOR=$$(echo "$(VERSION)" | cut -f1 -d'.'); \ | ||
| git tag --list "$${MAJOR}.*.*" 2>/dev/null | sort -V | awk -v ver="$(VERSION)" '$$0 < ver {latest=$$0} END {print latest}') |
There was a problem hiding this comment.
git tag --list problem with this is that users using git pull will not have all remote tags fetched and it will use local tags which are not up to date. So it will not work when running from local unless users explicitly fetch all tags. I'm not sure what is happening when running in GH action regarding tags
There was a problem hiding this comment.
Thanks a lot @FilipB !
You found an issue that for sure would happen.
I've added a command to fetch the git tags.
If execution of this command fails, the flow aborted.
During publish of the operator to OperatorHub, "PREVIOUS_VERSION" variable is used to configure upgrade path for FBC. Currently, this variable is maintainer manually and in case of missing update to the relevant version, leads to a gate job failure. Automate "PREVIOUS_VERSION" variable detection, based on the "VERSION" variable, which is updated as part of the release flow and based on "git tag" detection to catch the latest released version. Signed-off-by: Maxim Babushkin <mbabushk@redhat.com>
MaxBab
force-pushed
the
automate_fbc_upgrade_graph_flow
branch
from
1a2a9aa to
7b4add8
Compare
|
@MaxBab: The following test failed, say
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. |
3 participants
What type of PR is this?
What this PR does / why we need it:
During publish of the operator to OperatorHub, "PREVIOUS_VERSION" variable is used to configure upgrade path for FBC. Currently, this variable is maintainer manually and in case of missing update to the relevant version, leads to a gate job failure.
Automate "PREVIOUS_VERSION" variable detection, based on the "VERSION" variable, which is updated as part of the release flow and based on "git tag" detection to catch the latest released version.
Which issue(s) this PR fixes:
Fixes #1982
Related Issue/PR #
Additional information: