Remove CODEOWNERS and fix maintainer-approval in merge queue#4931
Merged
simonfaltum merged 8 commits intomainfrom Apr 13, 2026
Merged
Remove CODEOWNERS and fix maintainer-approval in merge queue#4931simonfaltum merged 8 commits intomainfrom
simonfaltum merged 8 commits intomainfrom
Conversation
Approval is now enforced through the maintainer-approval GitHub Action (required status check) and the OWNERS file, rather than GitHub's built-in CODEOWNERS mechanism. This gives us more flexible per-path approval logic while keeping the same ownership rules. Co-authored-by: Isaac
simonfaltum
requested review from
andrewnester,
anton-107,
denik,
pietern and
shreyas-goenka
as code owners
simonfaltum
removed request for
andrewnester,
anton-107,
denik and
shreyas-goenka
Co-authored-by: Isaac
Co-authored-by: Isaac
Adds support for "team:<name>" aliases in the OWNERS file. Teams are defined in .github/OWNERTEAMS and expanded by the owners.js parser. This avoids repeating long member lists on every line. Defines team:platform (PAE) and team:bundle, and updates OWNERS to use them. Co-authored-by: Isaac
…rom template owners Extract shared line-parsing logic into readDataLines helper. Replace existsSync+readFileSync with try/catch ENOENT. Remove simonfaltum from /libs/template/ owners. Co-authored-by: Isaac
pietern
approved these changes
Apr 13, 2026
.github/OWNERTEAMS
Outdated
| # Use "team:<name>" in OWNERS to reference a team defined here. | ||
| # Format: team:<name> @member1 @member2 ... | ||
|
|
||
| team:bundle @andrewnester @anton-107 @denik @pietern @shreyas-goenka |
Co-authored-by: Isaac
The maintainer-approval workflow only triggers on pull_request_target and pull_request_review events, so the status is never set on the merge queue commit. This adds a merge_group trigger that auto-approves the status, following the same pattern as the Integration Tests check. Co-authored-by: Isaac
Commit statuses are not clickable in the GitHub UI. Check runs show a details page with logs and output summary. This makes it easier to see why a PR is pending or who approved it. Co-authored-by: Isaac
simonfaltum
changed the title
2 tasks
simonfaltum
added a commit
that referenced
this pull request
Apr 13, 2026
The previous change (PR #4931) switched maintainer-approval from commit statuses to check runs. However, check runs with status "in_progress" are treated by GitHub as "still running" and don't block the required status check, so all PRs could merge without approval. Fix: for approved PRs, create a success check run (green, clickable). For pending PRs, create nothing. The required status check stays as "Expected" in GitHub (yellow dot), which blocks the merge until approval is granted. Co-authored-by: Isaac
github-merge-queue bot
pushed a commit
that referenced
this pull request
Apr 13, 2026
## Why PR #4931 switched `maintainer-approval` from commit statuses (`createCommitStatus`) to check runs (`checks.create`) so the check is clickable in the GitHub UI. The pending state used `status: "in_progress"`, which GitHub treats as "still running" rather than "blocking". This meant all PRs could merge without maintainer approval. ## Changes Removes the three `checks.create` calls for pending states (wildcard files, uncovered groups, no approval). When no check run or status exists for `maintainer-approval` on a SHA, GitHub shows the required check as "Expected" (yellow dot) and blocks the merge. Approved PRs still get a success check run (green, clickable). The result: - **No approval**: yellow dot, merge blocked, reviewer info in PR comment - **Approved**: green checkmark, clickable, shows who approved - **Merge queue**: green checkmark, auto-approved (unchanged) ## Test plan - [x] All 20 tests in `maintainer-approval.test.js` pass - [ ] Verify on a subsequent PR (after merge) that `maintainer-approval` shows yellow "Expected" without approval, then turns green after approval Note: the workflow uses `pull_request_target`, so it runs from main. This PR cannot test itself.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Approval enforcement is now handled by the
maintainer-approvalGitHub Action and the.github/OWNERSfile. GitHub's built-in CODEOWNERS is no longer needed.The
maintainer-approvalworkflow only triggers onpull_request_targetandpull_request_reviewevents. It never runs formerge_groupevents, so the status is never set on the merge queue commit. This blocks the merge queue indefinitely.maintainer-approvaluses commit statuses (createCommitStatus), which are not clickable in the GitHub checks UI. Check runs (checks.create) show a details page with logs and output.Changes
CODEOWNERS removal: Removes
.github/CODEOWNERS. The.github/OWNERSfile already contains the same ownership rules, and the maintainer-approval workflow reads from OWNERS.Merge queue fix: Adds
merge_grouptrigger to themaintainer-approvalworkflow with an auto-approve job. PRs are already approved before entering the merge queue, so the job sets a passing check on the merge queue commit. This follows the same pattern as theIntegration Testsauto-approve inpush.yml.Commit status to check run: Migrates all
createCommitStatuscalls tochecks.createin both the JS script and the YAML workflow. Permissions updated fromstatuses: writetochecks: write. Thecheckjob is also guarded withgithub.event_name != 'merge_group'to prevent it from running (and failing) on merge queue events.Test plan
maintainer-approvalis a required status check on mainmaintainer-approval.test.jspass with the check run migration