-
-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for backport-style PRs #1074
Comments
@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) |
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.
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:
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. |
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 |
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 |
Thank you for providing your workaround. |
While not the real solution for this ask. the new json output of the action may be helpful in some form: #1113 (comment) |
- FIX #1074 - optimize placeholder removal - only keep placeholders in array if we have values
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 |
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.
The text was updated successfully, but these errors were encountered: