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-test...@lists.llvm.org <mailto:release-test...@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).
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).
-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-test...@lists.llvm.org <mailto:release-test...@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
<https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
