Replace commit status with workflow result

[MikeMcQuaid]

• Fail validation through the workflow for read-only fork tokens.
• Preserve existing package-repository label management.
• Document Issues permissions and branch protection migration.

[Copilot]

🟡 Not ready to approve

There are remaining correctness and documentation issues (workflow not failing for multi-cask violations; permissions guidance mismatches the action’s Issues API usage).

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR updates the check-commit-format GitHub Action to stop writing legacy commit statuses and instead reflect validation failures through the workflow/job result, while keeping PR label management behavior and documenting the permissions/branch-protection migration.

Changes:

• Remove GitHub Statuses API writes (repos.createCommitStatus) from the action implementation.
• Fail the workflow directly via core.setFailed(...) when commit validation fails, and update tests accordingly.
• Update README guidance to cover permissions and branch protection migration from status checks to workflow job requirements.

File summaries

File	Description
check-commit-format/main.mts	Removes commit-status writes and switches failure signaling to workflow failures while keeping label updates.
check-commit-format/main.test.mts	Updates tests to stop expecting status API calls and to assert workflow failures via thrown errors.
check-commit-format/README.md	Updates usage example, permissions guidance, and branch protection migration note.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 4
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟡 Not ready to approve

A label-update permission error can currently mask the intended validation failure message (notably for fork PR tokens), and the README token/permissions wording is ambiguous.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (2)

check-commit-format/README.md:27

• The README’s token/permissions wording is ambiguous: workflow permissions: only affects the default ${{ github.token }}, not a custom token passed via with: token:. Clarifying this helps users understand when permissions vs. token scopes apply, especially for fork PRs where write permissions are downgraded.

The token needs `contents: read` and `pull-requests: read`. Package-repository
label management additionally needs `issues: write`, as shown above.

check-commit-format/main.mts:211

• If updating PR labels fails (e.g., on fork PRs where the GITHUB_TOKEN is read-only), the thrown API error will be caught and reported via core.setFailed(error), which can hide the more useful commit-format failure message. Consider marking the workflow failed before attempting label updates, and treating label update failures as best-effort when a validation failure has already been detected.

        if (existingLabels.length != updatedLabels.length || !existingLabels.every((label, i) => label == updatedLabels[i])) {
            await client.rest.issues.update({
                ...github.context.repo,
                issue_number: pull.number,
                labels: updatedLabels

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[andrew]

Looks good, this unblocks fork PRs on Homebrew/brew (and is the missing half of Homebrew/brew#23402, which currently pins a SHA that no longer exists here).

One non-blocking note for the package-repo path: at main.mts:207-215, issues.update runs before core.setFailed(failure_message). Fork pull_request tokens get issues: write downgraded to read (same as statuses), so if the label update throws, the outer catch reports the HTTP error and the validation message is lost. Previously the status was posted before this call so the message survived. Calling core.setFailed(failure_message) before the label block, or wrapping the update in try/catch with core.warning, would keep the useful message. Doesn't affect the check_package_commit_format: false case brew uses, so not blocking.