Ask
Extend check-github-config (and config/github.yml) to also check the Actions "Workflow permissions" repo settings: default_workflow_permissions and can_approve_pull_request_reviews.
Why
In rubykatzen/flightdeck, a silently-restrictive default_workflow_permissions: "read" (with can_approve_pull_request_reviews: false) broke two workflows completely for weeks without anyone noticing:
Release — action_required, zero jobs ever ran, even though the workflow explicitly declares permissions: contents: write / issues: write / pull-requests: write itself. The repo-level setting is a hard ceiling; a workflow's own permissions: block can only narrow it, never exceed it.Notify Telegram PR — startup_failure on every run, including the daily schedule trigger (so this wasn't a PR/fork-specific thing), because a nested reusable-workflow job needed pull-requests: read and the repo only allowed pull-requests: none.
Both were silent config drift — exactly the class of problem check-github-config already exists to catch for hasWikiEnabled/deleteBranchOnMerge/etc. Would've caught this in CI instead of us reverse-engineering it from GitHub's error banners after the fact.
Technical note
These two fields aren't exposed via GraphQL on the Repository type (checked the schema — no defaultWorkflowPermissions/canApprovePullRequestReviews-shaped field exists there). They're REST-only, under GET /repos/{owner}/{repo}/actions/permissions/workflow. check-github-config's current mechanism (github_repository() in check.py) is a single GraphQL query against arbitrary Repository field names, so this isn't just another key under config/github.yml's config: mapping — it needs a second, REST-based check path alongside the existing GraphQL one.
Ask
Extend
check-github-config(andconfig/github.yml) to also check the Actions "Workflow permissions" repo settings:default_workflow_permissionsandcan_approve_pull_request_reviews.Why
In
rubykatzen/flightdeck, a silently-restrictivedefault_workflow_permissions: "read"(withcan_approve_pull_request_reviews: false) broke two workflows completely for weeks without anyone noticing:Release—action_required, zero jobs ever ran, even though the workflow explicitly declarespermissions: contents: write / issues: write / pull-requests: writeitself. The repo-level setting is a hard ceiling; a workflow's ownpermissions:block can only narrow it, never exceed it.Notify Telegram PR—startup_failureon every run, including the dailyscheduletrigger (so this wasn't a PR/fork-specific thing), because a nested reusable-workflow job neededpull-requests: readand the repo only allowedpull-requests: none.Both were silent config drift — exactly the class of problem
check-github-configalready exists to catch forhasWikiEnabled/deleteBranchOnMerge/etc. Would've caught this in CI instead of us reverse-engineering it from GitHub's error banners after the fact.Technical note
These two fields aren't exposed via GraphQL on the
Repositorytype (checked the schema — nodefaultWorkflowPermissions/canApprovePullRequestReviews-shaped field exists there). They're REST-only, underGET /repos/{owner}/{repo}/actions/permissions/workflow.check-github-config's current mechanism (github_repository()incheck.py) is a single GraphQL query against arbitraryRepositoryfield names, so this isn't just another key underconfig/github.yml'sconfig:mapping — it needs a second, REST-based check path alongside the existing GraphQL one.