Skip to content

ci: wire merge_group triggers into required-check workflows - #1582

Open
eric-wang-1990 wants to merge 4 commits into
mainfrom
eric-wang/merge-queue-triggers
Open

ci: wire merge_group triggers into required-check workflows#1582
eric-wang-1990 wants to merge 4 commits into
mainfrom
eric-wang/merge-queue-triggers

Conversation

@eric-wang-1990

@eric-wang-1990 eric-wang-1990 commented Jul 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

What

Wires merge_group triggers into the required-check workflows the repo's existing merge-queue sender does not already cover, so all required checks report on the queued merge commit and the merge queue can be enabled without deadlock.

Context: an integration-test merge-queue sender already exists

trigger-integration-tests.yml already implements the merge-queue flow for the JDBC Integration Tests required check:

  • Ordinary PR → skip-integration-tests-pr posts a green stub for JDBC Integration Tests.
  • integration-test label → previews the real run (dispatched to databricks-driver-test, replay-only, thrift + sea).
  • Merge queue → merge-queue-jdbc is the real required gate (replay dispatch to driver-test).
  • remove-label-on-new-commit drops the approval label on new commits (the re-approval security control).

That workflow handles the integration gate. It does not wire the repo's other required checks for the queue. This PR fills exactly that gap.

Required checks on main and how each is covered in the queue

Required check Workflow Queue coverage
JDBC Integration Tests trigger-integration-tests.yml ✅ Already handled (pre-existing) — not touched by this PR
unit-tests (6 variants), formatting, packaging prCheck.yml This PR: + merge_group — runs for real against the merge commit (checkout already falls back to github.ref_name/github.repository; secret steps gated on push, so no secrets in queue)
freeze-check releaseFreeze.yml This PR: + merge_group + job-level skip — PR-semantic gate, already enforced at PR time; skipped required check counts as pass under classic branch protection
check-next-changelog checkNextChangelog.yml This PR: same skip-in-queue pattern

prIntegrationTests.yml is intentionally not wired for the queue — the integration gate is already merge-queue-jdbc; a second local mocked run would be a redundant, non-required duplicate that only adds latency.

Why the job-level skip is safe here

main uses classic branch protection (required_status_checks, strict: true; the two repo rulesets are unrelated). Under classic protection a skipped required check counts as a pass, so skipping the two PR-semantic jobs in the queue does not block it. They read github.event.pull_request.* (body/diff), which doesn't exist in the merge_group context, so they must not execute there.

Scope / follow-ups (NOT in this PR)

  • ❌ Enabling "Require merge queue" on the branch rule.
  • ❌ Any change to the existing trigger-integration-tests.yml sender.
  • ❌ Pre-merge live (passthrough) E2E — by design the integration gate is replay-only; live remains manual/nightly in driver-test.

Enabling the queue itself should be paired with the standard guardrails (required approval + dismiss-stale-reviews); note the integration sender already enforces re-approval on new commits via remove-label-on-new-commit.

NO_CHANGELOG=true

This pull request and its description were written by Isaac.

@eric-wang-1990
eric-wang-1990 requested a review from a team as a code owner July 24, 2026 21:29
Copilot AI reviewed Jul 24, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@eric-wang-1990
ci: wire merge_group triggers into required-check workflows
556193e 
Prerequisite for enabling a merge queue on `main`. GitHub's merge queue
waits for the branch's required status checks to report on the queued
merge commit via the `merge_group` event. None of the current
required-check workflows listen for `merge_group`, so turning on
"Require merge queue" today would hang every PR in the queue forever
(checks never report -> never merges).

This adds `merge_group` triggers to the four workflows backing the
required checks on `main`:

- prCheck.yml (unit-tests, formatting, packaging): runs for real against
  the merge commit. Checkout already falls back to github.ref_name /
  github.repository when the pull_request context is absent, and its
  secret-bearing steps are already gated on `github.event_name == 'push'`,
  so no secrets are exposed in the queue.
- prIntegrationTests.yml (JDBC integration tests): runs mocked against the
  merge commit, no secrets (unchanged posture).
- releaseFreeze.yml / checkNextChangelog.yml: these are PR-semantic gates
  that read github.event.pull_request.* (body/diff), which do not exist in
  the merge_group context. They already enforce at PR time, so in the queue
  their steps are guarded to no-op to success rather than fail on missing
  PR payload.

This PR only prevents the deadlock. It does NOT enable the queue or add
pre-merge live E2E. Enabling the queue and adding a secret-bearing
merge_group job must be paired with branch-protection guardrails
(required approval + dismiss-stale-reviews) so secrets only ever run
against human-approved fork code.

NO_CHANGELOG=true

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>
@eric-wang-1990
ci: simplify merge_group guards to a single job-level if
0779024 
Replace the per-step `if: github.event_name != 'merge_group'` guards (and
the extra "Skip in merge queue" echo step) with one job-level `if:` on the
freeze-check and check-next-changelog jobs.

`main` uses classic branch protection (required_status_checks, strict),
under which a skipped required check counts as a pass — so a job-level
skip does not block the merge queue. This is equivalent behavior with far
less noise than guarding every step.

NO_CHANGELOG=true

Co-authored-by: Isaac
Signed-off-by: eric-wang-1990 <e.wang@databricks.com>
@eric-wang-1990
eric-wang-1990 force-pushed the eric-wang/merge-queue-triggers branch from 7124e20 to 0779024 Compare July 24, 2026 21:51
@eric-wang-1990
ci: drop merge_group from prIntegrationTests (already gated by driver…
8167219 
…-test)

The `JDBC Integration Tests` required check is synthesized by
trigger-integration-tests.yml: an ordinary PR gets a green stub
(skip-integration-tests-pr), and the real required gate in the merge queue
is merge-queue-jdbc, which dispatches a replay-only run (thrift + sea) to
databricks-driver-test. Running the local mocked prIntegrationTests suite
in the queue too would be a redundant, non-required duplicate gate that
only adds latency. Revert that trigger; leave prIntegrationTests as a
PR-only mocked check.

The remaining merge_group wiring in this PR covers the required checks the
existing sender does NOT handle: unit-tests (prCheck), freeze-check, and
check-next-changelog.

NO_CHANGELOG=true

Signed-off-by: eric-wang-1990 <e.wang@databricks.com>
@eric-wang-1990
ci: post JDBC Integration Tests stub as the App via workflow_run repo…
62b5ef1 
…rter

Branch protection now pins the required `JDBC Integration Tests` check to the
integration-test GitHub App, so a check of that name posted by github-actions
(github.token) no longer satisfies the gate.

The old inline skip-integration-tests-pr job posted the PR-head stub as
github-actions and ran in a `pull_request` context — which has no secret access
on fork PRs, so it could not mint the App token to post as the App. That would
block every fork PR from satisfying the gate.

Port the databricks-sql-go pattern: move the stub into a new
skip-checks-reporter.yml that runs on `workflow_run` of "Trigger Integration
Tests". workflow_run executes in the base-repo context with secret access even
when the triggering run came from a fork, so it can mint the App token and post
the `JDBC Integration Tests` stub AS THE App for any PR head, fork or not.

The two `if: failure()` dispatch-error fallbacks stay on github.token
(best-effort error paths, mirrors sql-go). The real gate is unchanged:
merge-queue-jdbc dispatches to driver-test, whose receiver posts the real
App-attributed check on the merge_group commit.

NO_CHANGELOG=true

Signed-off-by: eric-wang-1990 <e.wang@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot Copilot left review comments
@gopalldb gopalldb Awaiting requested review from gopalldb gopalldb is a code owner automatically assigned from databricks/eng-oss-sql-driver
@shivam2680 shivam2680 Awaiting requested review from shivam2680 shivam2680 is a code owner automatically assigned from databricks/eng-oss-sql-driver
@msrathore-db msrathore-db Awaiting requested review from msrathore-db msrathore-db is a code owner automatically assigned from databricks/eng-oss-sql-driver
@jadewang-db jadewang-db Awaiting requested review from jadewang-db

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@eric-wang-1990