-
Notifications
You must be signed in to change notification settings - Fork 1
CI: an advisory PR-shape job — #510 leg 1's other half #597
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
61ec09d
CI: an advisory PR-shape job — #510 leg 1's other half
378e87c
pr-shape: merge-guard takes PRs positionally, not --pr
5980127
--shape-only: skip leg 2 as well — a run cannot judge a gate it contains
6ee6b07
--shape-only must not read the authority file it never uses
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
Repository: nForma-AI/nForma-NEXT
Length of output: 232
🤖 get_repo_knowledge executed:
get_repo_knowledge nForma-AI/nForma-NEXT /tmp/coderabbit-repo-knowledge/nforma-ai-nforma-next-96a012f3/conventionsLength of output: 1591
🏁 Script executed:
Repository: nForma-AI/nForma-NEXT
Length of output: 2823
🏁 Script executed:
Repository: nForma-AI/nForma-NEXT
Length of output: 50379
🌐 Web query:
site:docs.github.com Actions GITHUB_TOKEN permissions statusCheckRollup checks read pull requests read GraphQL💡 Result:
To configure GITHUB_TOKEN permissions for GitHub Actions, use the permissions key within your workflow YAML file at either the workflow or job level [1][2]. When you define the permissions key, all omitted permissions are set to none [2]. The requested permissions relate to the following scopes in the workflow syntax: checks: Required for interacting with check runs and check suites (e.g., statusCheckRollup) [3][4]. pull-requests: Required for interacting with pull requests (e.g., reading PR metadata or creating comments) [3][4]. GraphQL operations using the GITHUB_TOKEN follow the same permission model as the REST API [5]. When making GraphQL queries or mutations, your token must be granted the appropriate scope (e.g., checks: read or pull-requests: read) in the permissions key [1][6]. If your token lacks the required permissions for a specific resource or operation, the GraphQL API will return an error [6][7]. Example configuration: jobs: job_name: permissions: checks: read pull-requests: read runs-on: ubuntu-latest steps: - run: | # Use GH_TOKEN with GraphQL or REST calls gh api graphql -f query='{ repository(owner: "owner", name: "repo") { pullRequest(number: 1) { checksUrl } } }' env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} Note that statuses and checks are distinct scopes; if you need to access commit statuses specifically, you must also define the statuses permission [4][2]. Because the GITHUB_TOKEN is a GitHub App installation access token, it is restricted to the repository containing the workflow [8].
Citations:
🏁 Script executed:
Repository: nForma-AI/nForma-NEXT
Length of output: 2058
🌐 Web query:
site:docs.github.com/en/graphql/reference/objects PullRequest statusCheckRollup checks permission💡 Result:
GitHub’s GraphQL
PullRequest.statusCheckRollupexposes the combined status and check information for the PR’s head ref. Itscontextsconnection returns individual status contexts and check runs.[1]To read these checks, the authenticated user/token generally needs repository Contents: read access; GitHub Apps should request the Checks: read repository permission. Write access is only needed to create or manage checks.[2]
Example:
{ repository(owner: "OWNER", name: "REPO") { pullRequest(number: 1) { statusCheckRollup { state contexts(first: 100) { nodes { ... on CheckRun { name status conclusion } } } } } } }[1] (docs.github.com)
[2] (docs.github.com)
Citations:
🌐 Web query:
GitHub Actions GITHUB_TOKEN statusCheckRollup pull-requests read checks read gh pr view💡 Result:
When using the GitHub CLI (
gh) within a GitHub Actions workflow, theGITHUB_TOKENrequires specific, explicit permissions to successfully executegh pr viewor similar commands that fetch detailed pull request data, such as thestatusCheckRollupfield [1][2][3]. Thegh pr viewcommand often implicitly requests nested fields via GraphQL [1][2]. If these fields are included in the query (whichghdoes by default forstatusCheckRollup), the API call will fail with a "Resource not accessible by integration" error unless the corresponding permissions are granted in the workflow'spermissionsblock [2][3]. To supportgh pr viewand the retrieval of status check information, you typically need to grant the following minimum read permissions in your job or workflow definition [3]: permissions: contents: read pull-requests: read checks: read statuses: read actions: read # Required for accessing workflow-run details under statusCheckRollup [1][2] repository-projects: read # Often required for additional metadata, depending on the PR/CLI version [3] Key Considerations: 1. Permission Scope: When you define apermissionsblock, it replaces the default permissions for that job [1][4]. If you do not include a permission, it defaults tonone, which is why explicit listing is necessary [5]. 2. GraphQL and Partial Results: Without theactions: readpermission, the GraphQL API may return a partial result or fail entirely when thestatusCheckRollupfield is involved, causing theghcommand to exit with an error [1][2]. 3. Principle of Least Privilege: Always grant only the permissions necessary for your specific tasks [6][7]. If your workflow only needs to read status checks, you can minimize the permissions to those specifically required (e.g.,checks: read,statuses: read,actions: read) [1][2]. 4. Private vs. Public: While public repositories have different default behaviors, the requirement for explicit permissions remains consistent in GitHub Actions to ensure secure access to private resources [3]. If you encounter persistent issues, verify if your command requires additional scopes such asissues: read(if fetching closing issues) orrepository-projects: read(if accessing project metadata) [3][8].Citations:
🌐 Web query:
site:cli.github.com/manual/gh_pr_view statusCheckRollup permissions checks read💡 Result:
The statusCheckRollup is a field available in the GitHub GraphQL API, specifically used when retrieving details about pull requests, such as through the gh pr view command [1]. Because statusCheckRollup is a field within the pull request object, it does not require unique, standalone permissions to access. Instead, you must have the standard read permissions required to view the pull request itself. If you have permission to access a repository and view its pull requests, you have the necessary authorization to read the statusCheckRollup data associated with those pull requests.
Citations:
🌐 Web query:
GitHub GraphQL statusCheckRollup GITHUB_TOKEN pull-requests read checks permission Resource not accessible by integration💡 Result:
The error "Resource not accessible by integration" when using
statusCheckRollupin the GitHub GraphQL API occurs because theGITHUB_TOKENused by your GitHub Actions workflow lacks the necessary granular permissions [1][2][3]. Despite the error message appearing generic, it specifically indicates that the token does not have the scope required to read the objects nested within thestatusCheckRollupfield [1][4]. To resolve this, you must explicitly grant the required permissions in your workflow'spermissionsblock [5][6]. BecausestatusCheckRollupoften aggregates information from multiple sources, the specific permissions required may vary based on your exact query, but the following configuration is commonly required for success [3]: permissions: contents: read pull-requests: read checks: read statuses: read actions: read # Required to access workflow run details within the status check rollup [1][2] If your workflow is running in a private repository, you may also need to includerepository-projects: read[3]. Key takeaways for troubleshooting: - Granular permissions: TheGITHUB_TOKENfollows the principle of least privilege [5][6]. Even if you havepull-requests: read, you must separately grantchecks: readandstatuses: readto access the status information, andactions: readif your query traverses into workflow run details [1][2][3]. - GraphQL paths: The error message often points to a specific path (e.g.,nodes.0.commit.statusCheckRollup.contexts.nodes.0.checkSuite.workflowRun) [1][2]. The presence ofworkflowRunin the path is a strong indicator that theactions: readpermission is missing [1]. - Scope limitations: If you are working in a repository with strict default permissions, ensure these are defined at the job level [6]. If you continue to face issues despite these permissions, verify that your repository or organization settings do not restrict theGITHUB_TOKENbeyond these requirements [6].Citations:
🌐 Web query:
site:github.com/cli/cli/issues/6274 statusCheckRollup permissions💡 Result:
The statusCheckRollup field in the GitHub GraphQL API is part of the pull request object and requires both checks: read and statuses: read permissions to access [1]. When performing actions that involve retrieving pull request information—such as using the GitHub CLI (gh)—users frequently encounter the error "Resource not accessible by integration" regarding statusCheckRollup if these specific permissions are missing from their workflow configuration [1]. To resolve this issue, ensure your GitHub Actions workflow includes the following permission scopes: permissions: pull-requests: read statuses: read checks: read Depending on the specific operation and repository visibility (public vs. private), you may also need additional permissions such as contents: read, actions: read, or repository-projects: read [1].
Citations:
🌐 Web query:
"statusCheckRollup" "checks: read" GitHub Actions💡 Result:
In GitHub Actions and the GitHub GraphQL API, statusCheckRollup is a field used to aggregate the status of various checks associated with a specific commit [1][2][3]. It provides a consolidated view of both modern check runs and legacy commit statuses, which determines whether a pull request can be merged based on configured branch protection rules [4][5]. When interacting with statusCheckRollup via the GitHub GraphQL API (often implicitly through commands like gh pr checks or gh pr view), proper permissions are required to ensure the integration or GitHub App can successfully read the aggregated data [1][4]. Specifically, GitHub Actions or other integrations often need both checks: read and statuses: read permissions granted to their token [1][4]. - checks: read: Required to access data from the modern GitHub Actions check runs API [4]. - statuses: read: Required to access the legacy commit status API, which statusCheckRollup also incorporates into its aggregate state [4]. If these permissions are missing, API calls will typically fail with an error such as Resource not accessible by integration [1][4]. Additionally, it is worth noting that while statusCheckRollup is a powerful way to summarize commit health, there have been documented instances where it may occasionally omit specific failing check suites, leading to a discrepancy between the API's reported state and the actual status visible in the GitHub UI [5].
Citations:
🌐 Web query:
github cli gh pr view statusCheckRollup query CheckRun StatusContext permissions checks statuses💡 Result:
The statusCheckRollup field in the GitHub CLI (gh) represents a GraphQL object used to aggregate the status of CI/CD checks and commit statuses for a pull request's latest commit [1][2][3]. GraphQL Structure and CLI Usage The GitHub CLI uses the statusCheckRollup field to populate information for commands like gh pr view and gh pr status [1][3][4]. Internally, the CLI uses specific GraphQL fragments to query this data. Depending on the need, it may query: 1. Aggregated counts: Using checkRunCountsByState and statusContextCountsByState, which provide efficient, high-level summaries of passing, failing, or pending checks [1][5][3]. 2. Detailed nodes: Using the contexts field to retrieve individual check runs (CheckRun) and legacy commit statuses (StatusContext), which contain granular details like names, URLs, conclusions, and statuses [1][6][7]. Key Object Types - CheckRun: Represents an individual CI check [6][8]. Key fields include name, status (e.g., COMPLETED, IN_PROGRESS), and conclusion (e.g., SUCCESS, FAILURE) [6][8]. - StatusContext: Represents legacy commit statuses, which typically have a context name and a state [1][6]. Permissions and Access Accessing statusCheckRollup data via the GitHub CLI or GraphQL API requires specific repository permissions [2]. - For GitHub Apps or fine-grained personal access tokens, the caller typically needs read access to checks and pull requests (often mapped to the Checks repository permission) [2][7]. - A common error ("Resource not accessible by...") occurs when a token lacks these specific permissions or when the CLI attempts to eagerly fetch fields that the token is not authorized to access [9][2]. Known Limitations - Performance: In large repositories, querying detailed nodes can be slow or time out, which is why the CLI has transitioned to using aggregated count fields where possible [5][3]. - Completeness: There have been reports where the statusCheckRollup (and consequently gh pr checks) may omit certain check suites, leading to discrepancies between the CLI output and the GitHub web UI, particularly for dynamic or GitHub-managed check suites [10]. - Consistency: Data returned by statusCheckRollup may differ from what is available via the REST API (e.g., GET /commits/{sha}/check-runs) [10].
Citations:
Grant read access to checks and statuses.
tools/merge-guard.pyrequestsstatusCheckRollup, which containsCheckRunandStatusContextdata. The job currently grants neitherchecks: readnorstatuses: read. GitHub can reject the query, causingpr_json()to return exit 2 without producing a shape result.🤖 Prompt for AI Agents
Source: Coding guidelines