Repository navigation
question(ci): audit required checks and merge-queue coverage before expanding enforcement #1736
Description
Question
Which existing and proposed deterministic checks should be required for Engram, and do their current event coverage, reliability and exact check names support that policy on both PRs and the merge queue?
Why does this need issue tracking?
This needs inspection of repository settings, workflow behavior and existing policy, followed by a durable maintainer decision. Workflow presence alone does not prove a check is required. Unstable or missing merge-group checks can block contributors or leave enforcement gaps.
Affected Area
Project workflow or policy.
Additional Context
Acceptance criteria:
- Record the actual current required contexts/rulesets and any inaccessible settings.
- Map each current required context to its workflow/job and relevant PR/merge-group events.
- Compare actual enforcement with CONTRIBUTING.md; distinguish existing behavior from proposals.
- Record failures/instability before recommending any new mandatory check.
- Evaluate the proposed dependency-review check separately from advisory PR-size and AI-review output.
- Produce a scoped recommendation with migration/rollback considerations and explicit owner approval.
- Do not mutate rulesets, add required checks or bypass existing gates as part of this audit.
Non-goals: reimplementing completed merge-queue compatibility, forcing unstable checks, or making AI verdicts authoritative.
Related prior work: #926 (merge-queue compatibility) and #1140 (required type-label check migration).
Companion configuration improvements should use focused PRs and remain separately reviewable.
Activity
dnlrsls commentedon Oct 9, 2026
Read-only audit: preserve the six current required contexts
The effective rules and workflow mapping support keeping the existing gates unchanged. This is a bounded diagnosis, not approval of new gates or completion of every acceptance criterion. Source was pinned to
b737f4a86ad0498727735fa376dc31f823a7607c; settings and history were observed live.Confirmed enforcement
15368, with strict status-check policyfalse.ALLGREEN,SQUASH, 60-minute timeout,max_entries_to_build=5,min_entries_to_merge=1,max_entries_to_merge=5, and five-minute minimum-group wait. Ordinary required approving-review count is zero; code-owner, last-push approval and thread-resolution requirements are false.unit-testspull_request;merge_group: checks_requestede2e-testsplugin-testscheck-issue-referencepull_request;merge_group: checks_requestedcheck-issue-approvedcheck-label-policypull_request_target;merge_group: checks_requestedMetadata validation uses trusted event-base helpers and current queued PR metadata. That does not make every inline workflow definition immutable. PR Validation omits
reopened; changing the approval label on a linked issue alone does not refresh the checks.Observed execution and limits
resp.Body.Close); a later revision passed. Validation 37897717217 correctly rejected fix(mcp): validate updates against the expected owner #1725's missing closing reference, then skipped dependent approval. One label cancellation was explicitly superseded by successful same-SHA runs; the other cause was not inspected. These samples are not a reliability guarantee.Proposed follow-ups, not approved changes
review_on_push=true, drafts excluded), distinct from a required status gate. Resolve that duplication explicitly under the one-advisory-reviewer policy.No rulesets, required checks, bypasses, source files, labels or issue state were changed by this audit. No builds/tests or forced workflow runs were performed. The issue remains open for owner decisions and missing evidence.
dnlrsls commentedon Oct 12, 2026
Audit completion: retain the six existing required contexts
The recommendation is to keep current enforcement unchanged. This closes the audit-only scope, not approval of new gates, implementation or administrator settings changes. The approval-event refresh is tracked separately in #1802.
Sources are pinned to
d134a555; effective main rules were freshly read on October 12, 2026.ci.yml / unit-testspull_request,merge_group: checks_requestedci.yml / e2e-testsci.yml / plugin-testspr-check.yml / check-issue-referencepull_request,merge_group: checks_requestedpr-check.yml / check-issue-approvedpr-label-check.yml / check-label-policypull_request_target,merge_group: checks_requested15368, strict policyfalseanddo_not_enforce_on_create=false. Queue policy remainsALLGREEN,SQUASH, build maximum 5, merge minimum 1/maximum 5, minimum-group wait 5 minutes, timeout 60 minutes.18ae0e69. The failure/cancellation samples in the earlier audit remain bounded observations, not a reliability guarantee.do_not_enforce_on_create=false. Any ruleset migration requires explicit owner/admin approval and an authorized administrator; no such grant is inferred here. Rollback must remove only a newly introduced requirement and preserve the six existing gates. The approval-refresh follow-up must preserve existing check names/provider binding and queue coverage.No rulesets, bypasses, workflows, required checks, repository permissions or app settings were changed. No local tests/builds or forced workflow runs were needed for this read-only refresh. Closing the audit does not close those separate follow-ups or claim missing rollout proof.