-
Notifications
You must be signed in to change notification settings - Fork 27
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
Port origin PR labels to backport PR #87
Comments
Hi @mweinelt. Thanks for the great idea. I can definitely see your and other use cases for this. There's some scoping to be done here though. For example, we could define a set of labels that are always set on backport pull requests, but we can also copy labels from the original pull request. Copying also comes with some interesting edges when considering which labels to copy, e.g. simply all labels, or all labels that are not a backport label (so it doesn't trigger the action again), all matching some configurable regex pattern, or all from a configurable set. I'd be curious to hear from you what would be most fitting to your case, so I can keep the initial change small but also consider how to expand it in the future. |
Thanks for getting back to me so fast. Flexibility wise I think regular expressions are the way to go. To keep complexity in check maybe allow a list of multiple simpler patterns that would each be sufficient for a label to be backported. Does that sound sensible to you? |
I'm not sure about this. Regular expressions already support matching to multiple patterns using the How about naming of the input? What do you think about |
I think what @mweinelt meant was something like pre-made regex patterns for simple cases that you could use instead of having to spin your own (possibly faulty) regex. "Every label but backport labels" is probably a property a large amount of users would want, so this common case could be built in as a convenience option. Otherwise, all those users would have to declare a regex for that themselves. It's a way to have maximum configurability while retaining ease of use which is something we quite like in the functional world ;) |
Hi, I think I'm here for the same reason as mweinelt :)
|
@lheckemann I would definitely welcome a PR for this, but let's agree first on the design. We might be able to simplify the feature by copying all non-backport labels. For example, a boolean input What do you think? EDIT: on second thought, that's exactly what @Atemu described 💡 "Every label but backport labels" |
Isn't an implementation based on a regex more flexible and similar easy to implement? Because I think there may be some labels we don't want to backport e.g. all our rebuild-xxx labels. I don't think we necessarily need to optimize for ease of use. Flexibility may be more important in my opinion if you want to keep the implementation simple. |
@mohe2015 That actually makes sense. Flexibility first, ease of use second. @lheckemann Let's go for the |
@lheckemann Please note that your code is based on changes that are currently under battle-testing in |
Allow a set of labels to be automatically applied onto the backport PR.
Use case for us (NixOS/nixpkgs) would be labels like
Severity: Security
, which also applies to the backport PR and right now needs to be remembered to be applied when the PR gets created.The text was updated successfully, but these errors were encountered: