Implement release locking to avoid publishing helm chart before container image #3940
Merged
Implement release locking to avoid publishing helm chart before container image #3940
Conversation
enekofb
force-pushed
the
implement-release-locking
branch
from
b0fb870 to
246e285
Compare
enekofb
requested review from
Himangini,
bigkevmcd,
chanwit,
hiddeco,
jpellizzari,
serboctor and
yiannistri
enekofb
force-pushed
the
implement-release-locking
branch
from
246e285 to
2759a31
Compare
Merged
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Closes #3907
What changed?
Implements locking action as suggested here
Why was this change made?
To reduce chances of release incident happened in v0.29 to happen in future release and simplify the releaser job.
How was this change implemented?
Added status check called 'release' with locking semantics around release and non-release workflows. It also includes
other enhancements from the original proposal like error prograpation while doing status checks update in github actions steps.
How did you validate the change?
The following scenarios has been tested in the context of the development repo. It will require to be validated for this repo once the code is merged.
for a non-release PR
A push into main does not require release status check
A PR to main does passes without any intervention
A PR to main that might fails the api endpoint call is stable and could be retried
for a release PR
A release PR to main merges without any intervention
A release PR to main that fails cannot be merged until the status check is not unlocked
Release notes
No
Documentation Changes
No