Add backport github action/workflow to all repos

[ghassanmas]

Firm Name

Zaatdev

Urgency

Low (2 weeks)

Problem/Request

We need a github action that would atuomate the process of creating a PR, I have tested this github action https://github.com/ghassanmas/edx-platform/blob/master/.github/workflows/backport.yml on my fork already.

My thinking is that this workflow would be added here https://github.com/openedx/.github/tree/master/.github/workflows with a spesfic name then it would be used on other repos as if it was imported openedx action/workflows. This is important because if in future we found somehting need to be changed about this workflow we wouldn't need to do X changes for X repos in openedx, and this tha pattern that currently exists for add-depre and label workflow.

Reasoning

Because we usually have many PRs to be backported to a release branch.

[openedx-workflow-automation]

Thank you for your report! @openedx/axim-oncall will triage within a business day. Simple requests usually take 2-3 business days to resolve; more complex requests could take longer.

[feanil]

@ghassanmas it sounds like you want to add a reusable workflow to openedx/.github, is the request here to make that change or to ask if it is okay to make that change, or something else?

[kdmccormick]

@feanil I have some context on this (I asked Ghassan to file the request) and I'm on call this week, so I don't mind taking this one on.

[kdmccormick]

@ghassanmas I have been thinking about this. It is useful to have actions available in every repo such as: backport, assign me, label: etc. However, it becomes burdensome to add, remove, and update all these actions when each action requires a separate:

• shared workflow in in https://github.com/openedx/.github, and
• wrapper workflow copied into every single repository -- any change requires merging 250+ PRs!

Furthermore, it will become hard for developers to remember how to trigger these actions if some of them are triggered by comments (assign me:, label:) and some of them are triggered by labels (backport).

Here is my proposal.

• Instead of labels, we make it so the backport action is triggered by a comment, for example backport: palm.
• We have one single shared workflow in .github, called comment-listener.yml. This shared workflow contains logic to handle all of the GitHub commands, including assign me, label:, remove-label:, and anything else that we want to add in the future.
• We copy one wrapper workflow into every single repository, which never has to change.
• Going forward, we will only need to edit comment-listener.yml in order to add, remove, or change any command.

Let me know what you think. If you like it, we can make this change, and backport: could be the first new command added to comment-listener.yml.

[ghassanmas]

Hey folks apologies for the late reply.

I think there are two distinct suggestions:

Resuable/Extensible worfklow

First we create an extendable workflow, which would need only to be used /refs in all repo once, and when we want to add new command, featuer...etc we only need to change from openedx/.github.

I indded agree with this, it would let us quickly create a new featuer/action.

Regarding using a comment instead of label

I think in theory, it wouldn't matter if a developer flag their intent that this PR needs to be backported to master, via comment or a label. there are few points to consider though:

1. Would a developer comment on PR, while it's being reviewed or after already it's has been merged:
   1. If they comment while it's being in review, then I suppose the backport hook, would be triggerd once PR merged and would scan previous comments that follows spesfic pattern: i.e. packport branch-name and do the backport.
   2. If developer is expected to comment only after PR has been merged, then it's doesn't need scan comments, and instead would take a branch name as arugment and directly create backport PR.
   3. case 1.i can also cover case 1.ii because it could be that it doesn't matter when the comment is posted, i.e. the logic can be as follow:
      1. A new backport comment on a PR (This assume the backport workflow can be triggered either though merge event or/and a comment)
         1. If the PR is already merged then try to directly open backport PR using branch name
         2. If the PR is not merged yet, then do nothing at this point.
            1. When the PR gets merged, our workflow will try to scan PR comments that meets spesfic critiera and create backport.

Other concern:

• The worflow I previously suggest and testsed https://github.com/marketplace/actions/backport-merged-pull-requests-to-selected-branches does support label but for comments, we might either probably need to extend it, or choose other wihch match our requirment from here: https://github.com/marketplace?type=&verification=&query=cherry-pick+ , or lastly create our own, assuming the efforts worth the outcomes.
• Sometimes automated backport might fail, or needs humans intervetion, when e.g. when git cherry-pick has a merge conflict

[kdmccormick]

@ghassanmas , I did not realize that in your workflow, the label causes the backport to be created only after the PR merges. That seems very helpful-- honestly a better UX than my comment-trigger proposal --because it lets people add the backport ... label at any time, and not have to worry about remembering to backport later. It also has the added benefit that the backport action is already written. My bad for missing those details in your original proposal.

Given that, I think we should stick with your original label-trigger proposal. Let me know if you disagree.

In order to implement your proposal, you will need to:

• Open a PR against .github to add both the reusable workflow (./.github/workflows) and the workflow template (./workflow-templates).
• Open a PR against the repo_checks script in repo_tools. You will need to add a new repo_check which ensures that every repository in the named release has your new workflow template. I recommend subclassing EnsureWorkflowTemplates, and overriding .workflow_templates and .is_relevant() so that it adds the correct workflow template to the correct repositories.
• Tag me in both PRs -- I can merge them and run repo_checks, which will generate a few dozen PRs (one PR for every named release repo). You can then approve and merge those PRs.

(Regarding my comment-listener.yml suggestion: I still would like to do that some day, but I don't think it is relevant to your proposal any more.)

[feanil]

@kdmccormick given that this work can now be self-service by making PRs and getting reviews on other repos, do you still need this ticket to track the work? Should it be closed or have the github-request label removed?

[brian-smith-tcril]

It seems to me that this issue should be transferred to the .github repo. I'll let @kdmccormick make that call though.