feature/question: Support for projects instead of labels?

[LekoArts]

Hello folks!

At https://github.com/gatsbyjs/gatsby we recently introduced a release process that includes the necessity for backports. We're only backporting to the current minor at the moment but already that feels like a hassle to do it all manual 😅 So we currently have a self-written CLI that interacts with GitHub's API to backport a specific PR (cherry-pick, create new PR, label it).

While researching better ways I stumbled upon your tool and really like it!

We're currently using a GitHub project (https://github.com/gatsbyjs/gatsby/projects/25) to organize all this. This tool uses labels to mark things for the bot.

So I guess this is more of an open-ended question:

Did you consider using projects instead of labels / why did you chose labels instead of a project?

At the moment we'd prefer project over labels as we already have - what feels like - too many labels. But we're surely not locked into this, open to changing this to labels after all.

We'll surely test it out nevertheless and if we'd after that still prefer project based, would you be open for accepting a PR from us adding this functionality? (Saying no is totally fine of course)

Thanks for the tool and taking the time to respond to this :)

[LekoArts]

Hi @codebytere 👋 In case you missed it

[codebytere]

@LekoArts hi! i did totally miss this, thanks for the ping!

I'd be curious what your envisioned workflow would be for projects? e.g how would you monitor the lifecycle of a given backport? Depending on how it's implemented I don't think i'd be against it on principle, but labels provide more of a 1:1 mapping for the backport process in my estimation which is why i think it might ultimately be a simpler model 🤔

[LekoArts]

I'd be curious what your envisioned workflow would be for projects? e.g how would you monitor the lifecycle of a given backport?

So what we currently do (and like) is via stages in a project: https://github.com/gatsbyjs/gatsby/projects/25

• Currently open PRs that merge to master/main are tagged with To cherry-pick
• Once that PR is in we can manually cherry-pick and move the original PR over to the Backport PR opened stage
• Once we merge the cherry-pick we move the original PR to Backported

While writing this down I realize that we miss the tracking of the cherry-picked PR itself.

Just for verbosity, with labels you track every stage, right?

but labels provide more of a 1:1 mapping for the backport process in my estimation

Thanks for the tool and answer! :)

[codebytere]

@LekoArts yes! There are four possible states in the cycle - a PR destined for backport to let's say 12-x-y will be tagged target/12-x-y.

Then, once the PR is merged, the bot will check out a new branch off 12-x-y, and cherry pick over each individual commit to it. If that fails, it falls back to trying to pick over the squash merge commit (if it exists) since sometimes that can succeed where the former fails. If both fail, it'll update the original with needs-manual-backport/12-x-y.

If either succeed, then it'll open up that new PR, update the original PR's label to say in-flight/12-x-y, copy over relevant labels, and potentially tag the owner of the original PR. Once that PR is merged, the original is updated to merged/12-x-y and the process completes.

Additionally, the bot can track manual backports, so if I e.g. open up a PR and fix conflicts after the bot failed, and then include Backport of #12345 in the PR body, it'll pick up tracking from there.

Last fun fact is the tracking works up the chain, so if i need a PR to go to 12, 11, and 10, and 12 is clean but 11 and 10 require the same manual, I can run the bot from the manual PR to 11 to target 10 and it'll track back to update the original.

[LekoArts]

Thanks for the explanation! I think once we're settled with our major release this week 😅 we'll try it out with labels. Thanks again for the tool! :)