[llvm-dev] [Release-testers] RFC: New Automated Release Workflow (using Issues and Pull Requests)
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 17 14:16:28 PST 2021
On Fri, Dec 17, 2021 at 1:52 PM Tom Stellard <tstellar at redhat.com> wrote:
> On 12/17/21 13:25, Mehdi AMINI wrote:
> > Hi,
> >
> >
> >
> >
> > On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via Release-testers <
> release-testers at lists.llvm.org <mailto:release-testers 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>
> >
> >
> >
> > 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
> //merge LGTM/ comment in the issue directly and let the action merge it for
> example.
> >
>
> Yes, it would be possible to emulate pull request features with GitHub
> Actions. You
> would also have to implement some kind of reporting mechanism to report
> results
> back to the issue. I personally don't think it would be worth the effort
> to
> do a lot of extra work to get what pull requests give us for free (someone
> else
> would be welcome to implement this if they wanted).
>
My main worry right now is to enable pull-request on the repo before we
manage to figure out the workflow with GitHub issues, and in particular the
story about how to manage notifications at the repo level.
> If we did decide we don't want to use Pull Requests in the main repo for
> this,
> I think the alternatives would be to use Pull Requests in the llvmbot
> repo, or just drop this part of the proposal (in which case I would go back
> to using Pull Request in my personal account for testing).
>
Using pull-requests on another mirror repo (even create a "release-testing"
repo for this) would at least segregate all this from the monorepo, which
would address my current issues with the whole "subscribed to all activity
or lose too much" that we have with GitHub.
--
Mehdi
>
> -Tom
>
> >
> >
> >
> > # 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
> >
> > _______________________________________________
> > Release-testers mailing list
> > Release-testers at lists.llvm.org <mailto:
> Release-testers at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers <
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211217/f5528572/attachment.html>
More information about the llvm-dev
mailing list