ci: automate backport labeling with PR checkbox
To streamline backporting for Stylix maintainers, PR authors could indicate whether their PR can be backported.
Ideally, the label CI would automatically add the backport label when a new checkbox (phrasing subject to improvement) is checked:
- [ ] Backport this PR
- [X] Backport this PR
This probably does not fit in the current "Things done" section:
https://github.com/nix-community/stylix/blob/5cd1e4ffd9d1ad06d5dc3c3b08d8687ce95e4a08/.github/PULL_REQUEST_TEMPLATE.md?plain=1#L9-L14
Either we inconveniently add a seperate section for this one checkmark, or the "Things done" section is appropriately renamed.
Either we inconveniently add a seperate section for this one checkmark, or the "Things done" section is appropriately renamed.
perhaps something "Info" or "Info for Reviewers", based on the comment below
Would be useful to also list the conditions where backporting is appropriate
To streamline backporting for Stylix maintainers, PR authors could indicate whether their PR can be backported.
This is handled in https://github.com/nix-community/stylix/pull/1756.
Ideally, the label CI would automatically add the backport label when a new checkbox (phrasing subject to improvement) is checked:
This is still to be done.
Ideally, the label CI would automatically add the backport label when a new checkbox (phrasing subject to improvement) is checked:
This is still to be done.
For about a month I noticed the stylix-automation bot sometimes adding the backport label. Whatever is causing this is bad because it adds the label when it is not supposed to. See https://github.com/nix-community/stylix/pull/1969 as a great example on its persistence.
Ideally, the label CI would automatically add the backport label when a new checkbox (phrasing subject to improvement) is checked:
This is still to be done.
For about a month I noticed the stylix-automation bot sometimes adding the backport label. Whatever is causing this is bad because it adds the label when it is not supposed to. See #1969 as a great example on its persistence.
this was done here to ensure our ci doesn't get out of sync, but I'll revert it as it seems to be causing too many issues.