cherry-picked PR

[tom-borcin]

Added functionality to leave comment and add [Merged] keyword to cherry-picked pull request. It is triggered by push event and searches the commit message for pull request number to be handled.

[projectgus]

I have quite a few comments, but I'm very excited to see this feature arriving. :)

[projectgus]

Suggest this would be easier to test and maintain as a standalone action. There isn't any conceptual relationship between this functionality and JIRA, and the script doesn't use any functions from the jira sync code.

[tom-borcin]

I plan to refactor the github-actions so it is standalone action. Unfortunately this requires much more effort than I anticipated initially and I suggest we address that in new pull request.

[projectgus]

Sometimes we actually do "close" a PR by doing something different to what the author originally intended, and with a totally different commit. We try to avoid this, but it's necessary sometimes.

Ideally this action would check if the commit author is the same as the author of any of the commits in the PR branch, and only continue if it is. However this is probably a rare enough occasion that you can consider it a "nice to have". :)

[tom-borcin]

Thank you for suggestion. I have noted this feature request and will implement it in the future.

[projectgus]

Our internal guide suggests writing "Merges ..." as well (which isn't a GitHub keyword) and then manually telling the author their PR has been cherry-picked. This is something I originally did a lot as it seemed more polite. However, in recenttimes most people (including me) don't do this any more and they will write "Closes" or "Fixes".

I will send you a link to the page, up to you if you prefer to update the script to make the original workflow convenient or update the workflow to match the current behaviour.

[tom-borcin]

I will update workflow after this functionality is live in github-actions.

[igrr]

@tom-borcin I would ask to address the two remaining requests, if you can:

• move this functionality into a standalone action (comment-on-push or similar?)
• handle the situation when the PR is closed by a commit unrelated to the PR.

I think the easiest way to handle the latter is to still require Merges <PR URL> comment in the commit message if the PR has been cherry-picked. The workflow would be:

1. If the PR is merged by cherry-picking, append Merges <PR URL> to the commit message. When the commit is merged to the main branch, Github will not automatically close the PR. Your action recognizes the word Merges in the commit message, checks that the PR is still open, leaves a comment thanking the contributor, changes the title, and closes the PR.
2. If the PR is being closed by an unrelated commit (e.g. we implement something that solves the problem which PR addressed, but in a different way), the developer uses Closes <PR URL> in the commit message instead, same as they do when closing issues. When the commit is merged into the main branch, Github automatically closes the PR. The action doesn't need to be leave a comment in this case, and doesn't need to change the title.

Besides that, there is one more thing we can address by this comment-on-push action. It is related to the backporting workflow. Currently we add Closes <issue URL> to the commit message when fixing the issue on the main branch. When the commit is merged, Github automatically closes the issue, leaving a note in the issue UI such as @espressif-bot closed this in de0a24e 1 day ago. When the commit is backported to one of the release branches, typically the commit message is not modified, and the commit still references the issue URL. However when such commit is merged into one of the release branches, Github no longer adds any comments into the PR. This makes it harder for issue reporters to track whether the fix is already available in a particular release or not. Sometimes we leave summary comments to tell which commits have fixed the issue (such as espressif/esp-idf#5990 (comment)), but this is not automated and isn't applied consistently.

I think we can use the same approach, triggering an action on a push event (this time for release branches only), detecting Closes in the commit message, and leaving the comment like This issue was fixed on branch release/X.Y with commit <ID>.

One idea I have is to let the action accept several arguments:

• Regex to search for.
• Template of the comment to leave. The template may contain Python formatting placeholders such as {commit_id} or {branch}, which will be expanded to the actual commit ID or branch name when generating the message.
• Whether to close the issue/PR (bool)
• Whether to change issue/PR title (optional string to add)

This way we can use the same action in both cases, specifying different arguments.

[tomassebestik]

@tom-borcin Can we close this PR?