-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release process: Wrong versions might be created if no minor exists #1705
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with /lifecycle rotten |
/remove-lifecycle rotten |
What happened:
If there is a stable branch named X (lets use real case 0.89.0)
releasing on main must first create a minor that will assign the next available release Y (0.90.0)
before issuing patch versions.
Otherwise it might create release 0.89.1 which is reserved for the stable branch.
This in turn cause both the new release and the old release to conflict on both U/S HCO,
and on D/S.
Note that it means that when there is a stable branch for Y, it won't start with patch x.y.0.
What you expected to happen:
We should add logic that prevent creating patch release on main for already existing stable branches.
How to reproduce it (as minimally and precisely as possible):
Don't :)
see #1611
which created a patch on main before creating a new minor which doesn't belong to a stable branch.
Anything else we need to know?:
Once it happened we had to revert the broken release PR, untag manually, delete release.
and recreate releases on both the branch and main,
Then HCO could bump correctly, without images getting overriden.
Additional possible follow ups:
either tag or quay / release isn't created it will send email / comment on the PR.
(checking in parallel if we can comment on post submits, on both good / bad flows)
it will fail directly, but with the above protection not sure we need.
We should assert that no minors are created on branches,
but they first created on main and then from there we branch.
Otherwise we would have problems like we had here (see PR desc)
#1791
and would need to create releases manually.
Environment:
/cc @RamLavi
Some notes that arent directly related to CNAO, but have similar affect.
Note: On HCO we had another case where a release on a branch was created after branching,
but before merging any PR on that branch on KMP (not related to CNAO).
It caused double tag on the same commit (one because main already was tagged), and
then when it selected which tag to use to push images, it took the old one (used
head -1
onan ambiguous list of tags, that should be avoided),
resulting in overriding the old image, breaking HCO and CNAO.
The text was updated successfully, but these errors were encountered: