Navigation Menu

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

Jump to bottom

x/build/cmd/releasebot: for beta releases, release step might not use same commit as in prepare step #36182

Closed
dmitshur opened this issue Dec 17, 2019 · 2 comments
Closed

x/build/cmd/releasebot: for beta releases, release step might not use same commit as in prepare step #36182

dmitshur opened this issue Dec 17, 2019 · 2 comments
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone
Go1.15

Comments

@dmitshur
Copy link
Contributor

dmitshur commented Dec 17, 2019 •
edited

Currently, the release process involves running releasebot first in prepare mode, then again in release mode. If a commit is merged to the relevant branch between the two runs, the two modes will not use the same commit, which is suboptimal.

This affects beta releases much more than all other releases, since beta releases are made from master branch. (Other releases uses release branches.)

CL 211583 improves the situation by not skipping tests during release step for beta releases.

A more predictable solution we can consider is one where the the prepare step selects a commit, and makes it so that when it tells you to run the -mode=release command, it includes the selected commit. That way, the release mode is guaranteed to run on the same commit as prepare, which seems better.

There are other ways we can consider reducing unpredictability of the prepare/release modes; this issue is to discuss those.

/cc @cagedmantis @toothrot @FiloSottile
@dmitshur dmitshur added Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 17, 2019
@dmitshur dmitshur added this to the Backlog milestone Dec 17, 2019
@toothrot toothrot modified the milestones: Backlog, Unreleased Dec 17, 2019
@toothrot toothrot mentioned this issue Dec 17, 2019
Closed
@dmitshur dmitshur self-assigned this May 29, 2020
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 29, 2020
@dmitshur dmitshur mentioned this issue May 30, 2020
Closed
@dmitshur
Copy link
Contributor Author

dmitshur commented May 30, 2020 •
edited

I think this issue is best split into two. One for beta releases (where master branch is used), and another for all other releases (where release-branches are used).

For beta releases, there is a legitimate possibility of a commit landing to master branch between the time -mode=prepare is started, and the time -mode=release is started. We don't have much control over CLs landing on master branch when doing a beta release, and even if we could, we wouldn't want to prevent people from fixing release-blocking issues on master during the time.

The fix for beta releases is simple and unambiguous, because we're not creating a version commit. We can just re-use the same commit on master branch that was used in -mode=prepare for -mode=release.

For all other release types, there is a much smaller risk of a backport CL landing to a release branch in between the time of -mode=prepare and -mode=release. Only a small set of release managers have access to submit CLs to release-branches, and we would be okay with temporarily freezing the release-branch for all CLs other than the one that bumps the VERSION file.

The fix for other beta release types will need more investigation, and it's lower priority.

I'll make the scope of this issue to be about just beta releases, and make it a release blocker for 1.15 beta1. Filed issue #39317 about the other release types.

@dmitshur dmitshur modified the milestones: Unreleased, Go1.15 May 30, 2020
@dmitshur dmitshur changed the title x/build/cmd/releasebot: release step may (small chance) use a different commit than prepare step x/build/cmd/releasebot: for beta releases, release step might not use same commit as in prepare step May 30, 2020
@gopherbot
Copy link

Change https://golang.org/cl/235777 mentions this issue: cmd/releasebot: use same master commit for beta releases

@golang golang locked and limited conversation to collaborators Jun 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Milestone
Go1.15
Development

No branches or pull requests
3 participants
@toothrot @dmitshur @gopherbot