Skip to content
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

Open
oshoval opened this issue Nov 12, 2023 · 5 comments
Open

Release process: Wrong versions might be created if no minor exists #1705

oshoval opened this issue Nov 12, 2023 · 5 comments

Comments

@oshoval
Copy link
Collaborator

oshoval commented Nov 12, 2023

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:

  1. We might want to add logic to post submit that in case
    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)
  2. We can consider adding additional checks, for example that if tag already exists
    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 on
an ambiguous list of tags, that should be avoided),
resulting in overriding the old image, breaking HCO and CNAO.

@kubevirt-bot
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@kubevirt-bot kubevirt-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 10, 2024
@oshoval
Copy link
Collaborator Author

oshoval commented Feb 11, 2024

/remove-lifecycle stale

@kubevirt-bot kubevirt-bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 11, 2024
@kubevirt-bot
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@kubevirt-bot kubevirt-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 15, 2024
@kubevirt-bot
Copy link
Collaborator

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

@kubevirt-bot kubevirt-bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Sep 14, 2024
@oshoval
Copy link
Collaborator Author

oshoval commented Sep 16, 2024

/remove-lifecycle rotten

@kubevirt-bot kubevirt-bot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants