Support for backport-style PRs

[jackkoenig]

Thanks for the great project, it's really great stuff.

My project has a development style where we have a main development branch and then long-lived "stable" branches. For changes that need to be applied to stable branches, we use Mergify to create backport PRs to stable branches. Here's an example backport PR. The issue I'm running in to, is that these backport PRs do not have the correct author, labels, nor PR message for our release notes generation using this action.

Is there some way to have the action "remap" or "resolve" PRs based on some function or regex of the originally detected PRs?

Alternatively I can work on improving our backport automation to propagate the information from the original PR, but I figured I would ask about this "remapping" idea.

[mikepenz]

@jackkoenig thank you very much.

That's an interesting usecase.

Practically it seems that mapping it in some sorts could work, given that the new PR will most likely be included in the resolved PRs.

Thinking if there may be other usecases which could also benefit from such functionality.

Overall it seems like a potential helpful functionality, however it would also have some limitations. (e.g. PRs mapped require to be in the range from fetched PRs -> as such more frequent)

[jackkoenig]

given that the new PR will most likely be included in the resolved PRs.

I think it's a reasonable requirement that a link or PR number exists in the backport PR's title or body. It would be pretty easy to express the remapping as a regular expression.

Thinking if there may be other usecases which could also benefit from such functionality.

Potentially grouping multiple PRs into a single release notes entry maybe? Sometimes you'll have a PR that adds a feature or something and breaks something else and then a follow on PR to fix the previous one without having had a release in the meantime. I usually handle this by just marking one of the PRs as excluded from the release notes, but perhaps expressing the relationship between the PRs could be nice so that you could automatically emit something like:

* Cool PR adding feature X (by @jackkoenig in #1234)
  * Also see #1235

e.g. PRs mapped require to be in the range from fetched PRs -> as such more frequent

Yeah that makes sense. I admit I don't fully understand the need to specify max number of PRs and time, is it mainly a runtime or Github API rate limiting-related issue? In any case, it makes sense that anything mapped to also needs to be in the fetched PRs.

[mikepenz]

I will look into this in the coming weeks, won't be able to give an ETA, but it will most likely be only in May

[jackkoenig]

This is not a prod or anything, I just wanted to share my perfectly serviceable workaround.

I made a custom Github action that checks all PRs. When it sees a backport PR (by matching (backport #<number>) in the PR title), it will copy the labels and body from the original PR to the backport. It works pretty well with the exception of authorship in the generated release notes: https://github.com/chipsalliance/chisel/blob/3be02ef079589a6a6a8bb2a3583d78dda0ecf3a4/.github/workflows/backport-fixup.yml, example generated release: https://github.com/chipsalliance/chisel/releases/tag/v5.0.0-RC2.

[mikepenz]

Thank you for providing your workaround.

[mikepenz]

While not the real solution for this ask. the new json output of the action may be helpful in some form: #1113 (comment)

[mikepenz]

With v4 there will now be a way to reference PRs: https://github.com/mikepenz/release-changelog-builder-action/pull/1133/files#diff-7bed9bc5c1116651b2cb14555fa0b7af85c8e4c1f42e0923bbc62a308a4d4375R402-R420