Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Automating Managing LTS branches #2

Closed
MylesBorins opened this issue Oct 24, 2017 · 6 comments
Closed

Automating Managing LTS branches #2

MylesBorins opened this issue Oct 24, 2017 · 6 comments
Labels

Comments

@MylesBorins
Copy link

MylesBorins commented Oct 24, 2017

How could we automate the process of creating the staging branches?

An idea to start:

perhaps we could use labels to mark issues that are approved for backporting and a bot could automate cherry-picking it to a staging branch. If it does not land cleanly it adds a label / pings a backporting team

edit:

I've pivoted this issue to be about the LTS branches rather than the release process, as they are slightly different problems

@MylesBorins MylesBorins changed the title Automating release process Automating release process and managing LTS branches Oct 24, 2017
@MylesBorins MylesBorins changed the title Automating release process and managing LTS branches Automating release process and Managing LTS branches Oct 24, 2017
@MylesBorins MylesBorins changed the title Automating release process and Managing LTS branches Automating Managing LTS branches Oct 24, 2017
@MylesBorins MylesBorins mentioned this issue Oct 24, 2017
@joyeecheung
Copy link
Member

IIUC correctly, right now we just backport every PR that has suitable semver labels? Or do lts-watch-x labels do the job?

@MylesBorins
Copy link
Author

@joyeecheung currently I use branch diff to generate a list of commits with a command line

branch-diff v6.x-staging upstream/v8.x --exclude-label semver-major,semver-minor,dont-land-on-v6.x,backport-requested-v6.x,backported-to-v6.x,baking-for-lts --filter-release

and then manually review every commit. The labels are all manual too 😅

@joyeecheung
Copy link
Member

joyeecheung commented Oct 24, 2017

@MylesBorins OK I think I get what you meant now, including certain labels instead of excluding? Yes right now that looks like too much manual pings.

@MylesBorins
Copy link
Author

@joyeecheung yup. We could definitely do that to flag the commits. We would need a bot that could poll for labels, land the commits, and push upstream.

TBQH at that point the landing of the commit isn't the biggest deal... it is more about the review of what should / shouldn't land. Although in thinking about it, if the process of landing the commit was abstracted from the review process it would likely be easier to onboard more reviewers, and potentially inspire folks to review their own PRs.

We would likely still need to audit the backlog of un labelled issues... but perhaps it would be easier to inspire people to label if it were an automated process...

@evanlucas
Copy link

So, I've used https://github.com/evanlucas/node-backport for the past few releases I've done, and it sure makes things easier. Warning: It's pretty raw at this point though.

@phillipj
Copy link
Member

We've already done lots of related work in the github bot, trying to backport PRs and add different labels: nodejs/github-bot/scripts/attempt-backport.js.

Initially it also added dont-land-on-* labels which got disabled after lots of discussions (nodejs/github-bot/acd5bc).

I assume it something similar you're suggesting @MylesBorins with the addition of actually pushing changes to git branches?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants