RFC: New Automated Release Workflow Part 2

LLVM Project
1

Hi,

I’ve finished implementing the initial Release Automation Proposal, and now I would like to propose adding another automated workflow to the repository. This new workflow would automatically create a backport request when an issue/bug is marked as ‘fixed’ in a commit message.

This new workflow would work like this:

  1. A developer commits a patch that fixes an bug/issue and references the fixed issue in the commit message like this: Fixes #123456 This is a special string that GitHub recognizes and is the only way to start this new workflow (for now).
  2. GitHub automatically closes the referenced issue.
  3. The issue closed event starts a GitHub Action which will create a second issue requesting that the commit that fixed the original bug/issue be backported to the latest release branch.
  4. At this point, the workflow from my previous proposal will take over and the commit will be automatically backported and tested in a feature branch before being reviewed by the Release Manager who will decide whether or not to commit the fix to the release branch.

A patch to implement this new workflow can be found here: ⚙ D119412 github: Automatically create backport requests for bugs referenced in commit messages

The one downside of this proposal is that it will likely lead to more notifications for people who are watching the llvm-project repo. Even though I think that issues filed using this new workflow will have less comments than if they would have been filed manually, I think this new workflow will lead to a lot more issues being filed and overall there will be more notification.

Is this something worthwhile to add to the repo?

1 Like
2

Correct me if I’m wrong, and given that we should have the Fixes string in every patch that fixes an issue, but doesn’t this mean that every bug fix (with the Fixes string) will end up being marked for potential intgration into the release branch?

Otherwise, the workflow sounds reasonable to me, although I’m not one watching the repo.

3

That’s correct, and I think it would be great if every bug fix received consideration for backporting to the release branch.

4

My concern would be for the amount of work this generates for the release manager, but I honestly have no idea about the volume of commits that fix issues. If it does turns out to be overwhelming, I could see a workflow where we do exactly what you describe here but only for issues that are tagged with a label “consider-for-release” or “release-14-candidate” or something like that.

Overall this sounds like a great way to get more fixes in the release, but like James I’m also not watching the repo.

1 Like
5

We’re so much more efficient now with the new automated workflow from part 1 that I think we can handle this extra load of bugs.

Yeah, that is a good idea. We’ll just have to see how many bugs we end up getting with this new workflow.

1 Like
6

This sounds very nice to me. I hope the committer of the bugfix also is put on CC on the new backport request issue, right?

7

I have not implemented this,but it’s on my TODO list. I would also like to try to CC the person who approved the patch on Phabricator, but this is a little bit more complicated because it requires having a mapping between Phabricator and Github logins.

8

Hi Tom, btw, did you consider an option of using the same (already automatically closed) issue rather than creating a new one? This is to decrease the number of (duplicated) issue and to have some of concerned persons on CC.

9

It’s already possible to reuse and existing closed issue for tracking the backports. It’s just that most people aren’t doing it this way. I think there are pros and cons to each approach.

Edit:
@anton-afanasyev I realize now you are talking about the proposal and not the current automation. My long-term goal for this would be to use pull requests. So instead of creating a new issue, a new pull request would be created. From a workflow stand-point it’s easier to transition from “Create a New Issue” to “Create a New Pull Request”, which is why I set it up this way.

1 Like