Files
onyx/.github/workflows
Nikolas Garza fac3c16ac5 ci(cherry-pick): cherry-pick a merged GitHub stack as one PR (#16463)
## Description

**Bug:** when a GitHub stack merges, each upper PR's merge event carries
its parent branch as `base.ref`. The `base.ref == 'main'` gate skips
them, so only the bottom PR gets a cherry-pick.

**Fix:**
- Drop the `base.ref` gate. Check the merge commits are on main through
the compare API.
- Read the PR's stack through GraphQL. Layers merged within 30s of each
other form one batch. Only the run for the top PR of a batch proceeds,
after waiting out the window.
- One `ods cherry-pick` call gets every SHA in the batch in stack order,
so the batch opens one PR. A conflict fails the whole batch and alerts
#cherry-pick-prs as today.
- A partially merged stack cherry-picks only the layers in that merge
batch.
- One checked layer picks the whole batch.
- Slack messages and the cherry-pick PR body show the stack.
- `workflow_dispatch` with only `pr_number` resolves the batch the same
way.
- Gate command failures now send the Slack failure alert.

## How Has This Been Tested?

- Ran the gate script locally against real PRs: Roshan's 6-layer stack
(#16366 to #16371), the lower layers of that stack, a partially merged
stack (#16322 to #16326), plain checked and unchecked PRs, a dispatch by
SHA, a disallowed merger, and a GraphQL error.
- Dispatched this branch's workflow with `pr_number=16371`. The gate
resolved all 6 PRs in order with `GITHUB_TOKEN`:
https://github.com/onyx-dot-app/onyx/actions/runs/39697078780. The
cherry-pick step failed because all 6 were already on release/v5.0 by
hand. `ods` fails on two empty cherry-picks in a row, which is a
separate `ods` bug.

## Additional Options

- [ ] [Optional] Please cherry-pick this PR to the latest release
version.
2026-10-22 00:07:20 +00:00
..