Atmos Pro now reports check status on GitHub merge queue commits

atmos describe affected --upload now works under GITHUB_EVENT_NAME=merge_group, so Atmos Pro can correctly conclude check runs on the synthetic commits GitHub creates when a PR enters a merge queue. To control what runs on those synthetic commits, declare a new settings.pro.merge_group.checks_requested.workflows block in your stack config and point it at the workflow you want the queue to dispatch (in most cases, the same plan workflow you already use for pull_request.synchronize).

What Changed

Until now, the CLI rejected merge_group events at the --upload boundary, and Atmos Pro had no way to correlate the synthetic merge-queue commits with stack-affected results. Required "Atmos Pro" checks would stay in Expected — Waiting for status to be reported until a delayed reconciler swept them.

This release lifts that guard and makes the CLI fully aware of merge-queue events:

• atmos describe affected --upload accepts GITHUB_EVENT_NAME=merge_group alongside pull_request and pull_request_target.
• The diff base is resolved from event.merge_group.base_sha (the target-branch commit the synthetic commit was merged on top of), with merge_group.head_sha and merge_group.base_ref used for upload correlation and target-branch derivation.
• The full settings.pro.merge_group schema rounds-trips through the upload payload, so the new optional merge_group.checks_requested.workflows block reaches Atmos Pro intact.

On the Atmos Pro side, check-suite webhooks filtered on head_branch matching gh-readonly-queue/<base>/pr-<N>-<sha> now drive a full check-run lifecycle: create on the synthetic SHA, watch for the customer's workflow to complete, and conclude (success / failure / no-affected-stacks neutral). Comment updates are posted to the originating PR so queue check resolution shows up on the same thread.

Why This Matters

GitHub merge queues add a second SHA to every PR's lifecycle: the PR head commit, then a synthetic merge commit when the PR enters the queue. Required status checks must report against both. Before this release, customers using merge queues with Atmos Pro saw the queue check run hang — there was no way for the CLI to upload the affected stacks against the synthetic SHA. This release closes that gap so a PR added to a merge queue gets the same affected-stacks correlation it gets on the PR itself.

Workflow filenames in settings.pro are arbitrary, so Atmos Pro cannot tell from a filename alone whether a workflow plans, applies, or does something else. Rather than infer queue behavior from your existing pull_request.synchronize block, declare what you want the queue to dispatch explicitly. That keeps the queue's check outcome deterministic and reviewable from stack config.

How to Use It

Declare a merge_group block

Add a merge_group block alongside pull_request and point it at the workflow you want dispatched on merge-queue synthetic commits. In most cases that is the same plan workflow you already use for pull_request.synchronize, optionally with stricter inputs (fail-on-drift, required approvals, etc.):

settings:
  pro:
    enabled: true
    pull_request:
      synchronize:
        workflows:
          atmos-terraform-plan.yaml:
            inputs:
              component: "{{ .atmos_component }}"
              stack: "{{ .atmos_stack }}"
    merge_group:
      checks_requested:
        workflows:
          atmos-terraform-plan.yaml:
            inputs:
              component: "{{ .atmos_component }}"
              stack: "{{ .atmos_stack }}"
              fail_on_drift: "true"

merge_group is a sibling of pull_request / release / drift_detection (not nested under pull_request). The only meaningful activity today is checks_requested. Apply continues to fire on pull_request.merged — not on merge_group events.

Resolution order

When Atmos Pro receives a merge-queue trigger for a stack, it picks the workflow to dispatch in this order:

1. settings.pro.merge_group.checks_requested.workflows if defined — the recommended path.
2. Otherwise, settings.pro.pull_request.synchronize.workflows is used as a backstop so existing customers do not regress when a queue is enabled. Because workflow filenames are arbitrary, this can dispatch a workflow that is not appropriate for the queue; treat it as transitional, not as a recommended configuration.
3. Otherwise, no workflow is dispatched.

Get Involved

See the full configuration reference for the schema, prerequisites, and migration notes. GitHub's docs on managing a merge queue are a good starting point if you have not enabled queues yet.