[llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

Tom Stellard via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 23 19:11:34 PST 2021


On 12/23/21 09:53, Renato Golin wrote:
> On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>     * On an existing issue or a newly created issue, a user who wants to backport
>     one or more commits to the release branch adds a comment:
> 
>     /cherry-pick <commit_sha> <..>
> 
> 
> Hi Tom,
> 
> Would this be *any* user or users with certain permissions in the repo (like code owners, release managers)?
> 

Any user can do this.

> Ignoring malicious action, *any* user creating a cherry-pick at any time, may create confusion if two users are trying to pick changes that need multiple (non-sequential) commits each.
> 
> An alternative would be to build a branch off the release branch (ex. "release-x.y.z-$username") and pick the commits on that branch, run the pre-commit tests, and then merge to the release branch if it's all green.
> 

This is actually how it works.  The cherry-picked commits get
pushed to a branch called issue<issue#> and the pull request is created
off of that branch.

-Tom

> Because the merge is atomic, and the tests passed on the alternative branch, the probability of the release branch breaking is lower.
> 
> Of course, interaction between the users' branches can still break, and well, further tests that are not present in the pre-commit tests, can also.
> 
> But with atomic merges of cherry-picks in a linear sequence will also make it easier to bisect in case anything goes wrong with the release candidate.
> 
> If only a subset of users can merge, then they'd do one at a time and this problem wouldn't be a big issue and we'd avoid a complicated infrastructure setup.
> 
> Does that make sense?
> 
> cheers,
> --renato



More information about the llvm-dev mailing list