Files
twenty/.github/workflows
Paul Rastoin 29747f5d6b ci: report required status checks on merge_group so the queue isn't blocked (#23275)
Follow-up to #23216, which added the `merge_group`-triggered
`upgrade-mutation-guard`. This makes the merge queue actually usable.

## Why

The merge queue waits for every **required status check** to report a
conclusion on the `merge_group` candidate commit, and there is no
queue-only subset: it uses the branch's required status checks. Our
required `ci-*-status-check` contexts only trigger on `pull_request`, so
on a queued PR they sit at "Expected - Waiting for status to be
reported" and block the queue until the status-check timeout (60 min),
which then counts them as failed.

Only `upgrade-mutation-guard` (from #23216) triggers on `merge_group`,
so today it is the only check that reports in the queue.

## What

Add a `merge_group` trigger to each of the seven required-check
workflows and short-circuit the expensive work so the check reports
success in seconds, while the full suite keeps running on `pull_request`
to gate PRs. `upgrade-mutation-guard` stays the only check the queue
genuinely validates against `main`.

Mechanism: on `merge_group` the root jobs skip, everything downstream
cascades to `skipped`, and the `always()`-gated `*-status-check` job
runs, sees no failing needs, and succeeds. Kept as the same job in the
same workflow so the required-check context is byte-identical to the
PR-level one (a separate pass-through workflow could register a
different context and not satisfy branch protection).

Per workflow:

- **ci-front**: trigger only. It already cascades -
`changed-files-check` is `pull_request`-only and `front-sb-build` gates
on `push || any_changed`, so nothing runs on `merge_group`.
- **ci-server**: trigger + `if: github.event_name != 'merge_group'` on
the three ungated root jobs (`changed-files-check`,
`upgrade-changed-files-check`,
`server-previous-version-upgrade-mutation-guard`). The guard would
otherwise fail on `merge_group` since `pull_request.base.sha` is empty
there; the queue-side guard in `ci-merge-queue.yaml` already covers that
case.
- **ci-sdk / ci-website / ci-test-docker-compose**: trigger + the same
guard on `changed-files-check`.
- **ci-twenty-apps**: trigger + the guard on `discover` (its
`ci`/`integration` jobs gate on `discover` output, so they cascade off).

## Settings note

This complements the branch-protection changes for the queue (enable the
queue, max group size 1, per #23216). If the branch has **other**
required checks beyond these seven whose workflows are
`pull_request`-only, they need the same `merge_group` treatment or the
queue will wait on them too.

---
_Generated by [Claude
Code](https://claude.ai/code/session_015mZozbvyvha1S6wsEVLBnF)_

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/23275?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
2026-07-24 15:18:26 +02:00
..