<div dir="ltr"><div dir="ltr">Hi,<div> </div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via Release-testers <<a href="mailto:release-testers@lists.llvm.org">release-testers@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Here is a proposal for a new automated workflow for managing parts of the release<br>
process.  I've been experimenting with this over the past few releases and<br>
now that we have migrated to GitHub issues, it would be possible for us to<br>
implement this in the main repo.<br>
<br>
The workflow is pretty straight forward, but it does use pull requests.  My<br>
idea is to enable pull requests for only this automated workflow and not<br>
for general development (i.e. We would still use Phabricator for code review).<br>
Let me know what you think about this:<br>
<br>
<br>
# Workflow<br>
<br>
* On an existing issue or a newly created issue, a user who wants to backport<br>
one or more commits to the release branch adds a comment:<br>
<br>
/cherry-pick <commit_sha> <..><br>
<br>
* This starts a GitHub Action job that attempts to cherry-pick the commit(s)<br>
to the current release branch.<br>
<br>
* If the commit(s) can be cherry-picked cleanly, then the GitHub Action:<br>
     * Pushes the result of the cherry-pick to a branch in the<br>
       llvmbot/llvm-project repo called issue<n>, where n is the number of the<br>
       GitHub Issue that launched the Action.<br>
<br>
     * Adds this comment on the issue: /branch llvmbot/llvm-project/issue<n><br>
<br>
     * Creates a pull request from llvmbot/llvm-project/issue<n> to<br>
       llvm/llvm-project/release/XX.x<br>
<br>
     * Adds a comment on the issue: /pull-request #<n><br>
       where n is the number of the pull request.<br>
<br>
* If the commit(s) can't be cherry-picked cleanly, then the GitHub Action job adds<br>
the release:cherry-pick-failed label to the issue and adds a comment:<br>
"Failed to cherry-pick <commit_sha> <..>" along with a link to the failing<br>
Action.<br>
<br>
* If a user has manually cherry-picked the fixes, resolved the conflicts, and<br>
pushed the result to a branch on github, they can automatically create a pull<br>
request by adding this comment to an issue: /branch <user>/<repo>/<branch><br>
<br>
* Once a pull request has been created, this launches more GitHub Actions<br>
to run pre-commit tests.<br>
<br>
* Once the tests complete successfully and the changes have been approved<br>
by the release manager, the pull request can me merged into the release branch.<br>
<br>
* After the pull request is merged, a GitHub Action automatically closes the<br>
associated issue.<br>
<br>
Some Examples:<br>
<br>
Cherry-pick success: <a href="https://github.com/tstellar/llvm-project/issues/729Cherry-pick" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729<br>
Cherry-pick</a> failure: <a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a><br>
Manual Branch comment: <a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a></blockquote><div><br></div><div><br></div><div>Since your workflow can trigger actions from comments in the issues, why do you need pull-requests at all? Can't you trigger the pre-merge testing action on the branch from the issue? Then you can "approve" it with a <i>/merge LGTM</i> comment in the issue directly and let the action merge it for example.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
<br>
# Motivation<br>
<br>
Why do this?  The goal is to make the release process more efficient and transparent.<br>
With this new workflow, users can get automatic and immediate feedback when a commit<br>
they want backported doesn't apply cleanly or introduces some test failures.  With<br>
the current process, these kinds of issues are communicated by the release manager,<br>
and it can be days or even weeks before a problem is discovered and communicated back<br>
to the users.<br>
<br>
Another advantage of this workflow is it introduces pre-commit CI to the release branch,<br>
which is important for the stability of the branch and the releases, but also gives<br>
the project an opportunity to experiment with new CI workflows in a way that<br>
does not disrupt development on the main branch.<br>
<br>
# Implementation<br>
<br>
If this proposal is accepted, I would plan to implement this for the LLVM 14 release cycle based<br>
on the following proof of concept that I have been testing for the last few releases:<br>
<br>
<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a><br>
<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a><br>
<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a><br>
<br>
Thanks,<br>
Tom<br>
<br>
_______________________________________________<br>
Release-testers mailing list<br>
<a href="mailto:Release-testers@lists.llvm.org" target="_blank">Release-testers@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers</a><br>
</blockquote></div></div>