Summary

This makes GitHub auto-merge usable for Ratatui PRs once maintainers are happy with the change but CI is still running.

The workflow change adds a single aggregate required job to the main CI workflow. The repository now has auto-merge enabled and an ensure checks pass ruleset that requires that required status context on main.

Why

Without a required status context, GitHub's auto-merge button is not useful for the maintainer flow we want. The goal is to let a maintainer review a PR, decide it is ready, click auto-merge, and move on without coming back later just to check whether the remaining jobs finished.

This does not relax the merge policy. GitHub's own auto-merge behavior is to merge only after all required reviews and required status checks are satisfied. This change gives GitHub a stable required status to wait on automatically.

Precedent

I have been using this same auto-merge pattern in ratatui/tui-widgets, where it has worked well for the intended maintainer flow: once a PR looks ready, I can enable auto-merge and let GitHub merge it after the remaining checks and review requirements are satisfied.

How it works

The new required job depends on the main CI jobs in .github/workflows/ci.yml and always runs after them. It fails if any required dependency fails, is cancelled, or is skipped.

The repository ruleset requires only this aggregate required context instead of requiring every individual matrix job separately. That gives GitHub one stable status to wait on while preserving the existing CI coverage.

Things to know

• Auto-merge is opt-in per PR. Maintainers still choose when to click it.
• It does not skip review requirements, status checks, labels, or any other protection rule.
• A PR with auto-merge enabled can still show as blocked while checks or required reviews are pending. That is expected.
• If something needs to merge normally, maintainers can still use the regular merge path or an allowed ruleset bypass. This is a convenience path, not a hard blocker.
• Existing open PRs may need a rebase or synchronize event after this lands so they pick up the new required workflow job.
• If a new required CI job is added later, it should be added to the required.needs list or it will not be represented by the aggregate gate.
• Jobs that are intentionally allowed to fail should be handled carefully before adding them to required.needs, because skipped, cancelled, and failed dependencies make the aggregate fail.

Current PR state

Auto-merge is already enabled on this PR. If you approve it and the required checks pass, GitHub will squash-merge it automatically; approving it is enough to let the PR merge once the remaining requirements are satisfied.

GitHub docs

• Automatically merging a pull request
• Managing auto-merge for pull requests in your repository
• About rulesets
• Require status checks to pass before merging
• About status checks
• Troubleshooting required status checks

Validation

• ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
• actionlint .github/workflows/ci.yml
• Verified ratatui/ratatui has allow_auto_merge: true
• Verified the active ensure checks pass ruleset requires status context required
• Verified this PR has squash auto-merge enabled and is blocked pending checks/review