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

[Tom Stellard via Release-testers]

On 12/17/21 16:47, David Blaikie wrote:
> Sounds pretty good to me - wouldn't mind knowing more about/a good summary of the effects of this on project/repo/etc notifications that Mehdi's mentioning. (be good to have a write up of the expected impact/options to then discuss - from the thread so far I understand some general/high level concerns, but it's not clear to me exactly how it plays out)
> 

The impact is really going to depend on the person and what notification preferences they
have/want.  If you are already watching the repo with the default settings, then you probably
won't notice much of a difference given the current volume of notifications.

If people want to give their notification preferences, I can try to look at how
this change will impact specific configurations.

-Tom


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