support Github stacks

[karlismelderis-mckinsey]

Tell us more.

some background

every week we open PRs for all dependencies there is - usually that amounts to 20-30 PRs.
we chose this approach so people don't have endless feed or PRs and they have time to check what's arriving.
(* I'm aware of auto merge but due to requirements we cannot use this option and human in the loop is mandatory)

all PRs are from main and all touch pnpm lock files

hence after merging 1-2 PRs everyone else is almost 100% guaranteed to be in conflict

what we have considered

• one PR with X commits and merge without squash
• stack PRs and work with them bottom up

I currently lean towards gh stack option - it give us nicer view, allows to work with each update separately and detect root cause of failures in smaller diff

could you please consider to add option to stack PRs instead of starting each from main?

I think Renovate is already working at one PR at a time so it should be possible to continue from state of the previous PR

[jamietanna]

I think this sounds like something that would be very good - and would be a chance to lead into splitting PRs (which has been talked about several times before i.e. #14628)

I think - right now - there aren't any public APIs we can take advantage of here, it appears to require gh stack. That's fine, but may impact some of the performance benefits we have right now with API-only interactions, rather than calling out to the CLI.

I do think that instead of a stacked PR, having grouping is a reasonable option (on its own and alongside)

One thing is - how would this work if one of the updates in the middle of the stack broke CI? Would you only want the first x PRs to get merged? How would we control the ordering?

[karlismelderis-mckinsey]

I'm not particularly concerned about order - even today we're not questioning in what order Renovate is opening PRs so same logic can stay.
although offering major version update and then minor doesn't make sense (this probably will be auto-fixed if you start from where previous PR left)

group per "technology" sound great - we can have create stack per group 💪
in our case I think we would need a one big pnpm stack due to conflicts

removing PR from stack will cause issues - all stack most likely will need to be recreated (you cannot expect all on day one, right 😅)

Thank you for picking this discussion up