The Docs workflow runs super-linter (the Lint job) on every pull request. On each run the job logs a GitHub API error, which makes the pipeline look broken and buries real findings in noise. Resolving it keeps the pipeline output clean and gives contributors a summary of the lint results.
What happens: On every pull request, super-linter attempts to post a summary comment on the pull request and the call fails:
[ERROR] Failed to call GitHub API (https://api.github.com/repos/PSModule/docs/issues/<n>/comments) with POST HTTP method: curl: (22) The requested URL returned error: 403
[ERROR] Error while posting pull request summary
super-linter also warns that its summary settings are inconsistent:
[WARN] ENABLE_GITHUB_ACTIONS_STEP_SUMMARY is set to true, ENABLE_GITHUB_PULL_REQUEST_SUMMARY_COMMENT is set to true, but SAVE_SUPER_LINTER_SUMMARY is set to false.
What is expected: The Lint job reports its results without any GitHub API errors, both in the workflow run summary and as a comment on the pull request.
Regression indicator: Pre-existing. The 403 already occurred on v8.6.0 pull request runs, logged at [WARN] level. v8.7.0 reworked the comment code path so the failure is now logged at [ERROR] level, and it enables the job step summary by default, which surfaces the extra inconsistency warning. Push runs on main are unaffected because there is no pull request to comment on.
Environment: super-linter v8.7.0, pinned in .github/workflows/Docs.yml as of #46.
Acceptance criteria:
- The
Lint job produces no GitHub API 403 errors on pull request runs.
- No super-linter summary-configuration warning is emitted.
- Lint results appear both in the run job summary and as a pull request comment.
- The job grants only the minimal additional scope needed (
pull-requests: write).
super-linter posts the pull request comment through the GitHub REST API (POST /repos/{owner}/{repo}/issues/{issue_number}/comments), which requires the pull-requests: write permission. The Lint job granted only contents: read, packages: read, and statuses: write, so the call returned 403.
Both a run job summary and a pull request comment are wanted, so the Lint job is granted pull-requests: write (in addition to the existing scopes), and both ENABLE_GITHUB_ACTIONS_STEP_SUMMARY and ENABLE_GITHUB_PULL_REQUEST_SUMMARY_COMMENT are enabled. SAVE_SUPER_LINTER_SUMMARY is required to build the summary that both surfaces render.
Pull requests opened from forks always receive a read-only GITHUB_TOKEN, so the comment is skipped for forks; the run job summary still shows the results there.
The
Docsworkflow runs super-linter (theLintjob) on every pull request. On each run the job logs a GitHub API error, which makes the pipeline look broken and buries real findings in noise. Resolving it keeps the pipeline output clean and gives contributors a summary of the lint results.What happens: On every pull request, super-linter attempts to post a summary comment on the pull request and the call fails:
super-linter also warns that its summary settings are inconsistent:
What is expected: The
Lintjob reports its results without any GitHub API errors, both in the workflow run summary and as a comment on the pull request.Regression indicator: Pre-existing. The
403already occurred onv8.6.0pull request runs, logged at[WARN]level.v8.7.0reworked the comment code path so the failure is now logged at[ERROR]level, and it enables the job step summary by default, which surfaces the extra inconsistency warning. Push runs onmainare unaffected because there is no pull request to comment on.Environment: super-linter
v8.7.0, pinned in.github/workflows/Docs.ymlas of #46.Acceptance criteria:
Lintjob produces no GitHub API403errors on pull request runs.pull-requests: write).super-linter posts the pull request comment through the GitHub REST API (
POST /repos/{owner}/{repo}/issues/{issue_number}/comments), which requires thepull-requests: writepermission. TheLintjob granted onlycontents: read,packages: read, andstatuses: write, so the call returned403.Both a run job summary and a pull request comment are wanted, so the
Lintjob is grantedpull-requests: write(in addition to the existing scopes), and bothENABLE_GITHUB_ACTIONS_STEP_SUMMARYandENABLE_GITHUB_PULL_REQUEST_SUMMARY_COMMENTare enabled.SAVE_SUPER_LINTER_SUMMARYis required to build the summary that both surfaces render.Pull requests opened from forks always receive a read-only
GITHUB_TOKEN, so the comment is skipped for forks; the run job summary still shows the results there..github/workflows/Docs.yml, grant theLintjobpull-requests: writeand setENABLE_GITHUB_ACTIONS_STEP_SUMMARY: true,ENABLE_GITHUB_PULL_REQUEST_SUMMARY_COMMENT: true, andSAVE_SUPER_LINTER_SUMMARY: true.403error, a posted summary comment, and no summary-configuration warning.