Update pr-checks.yml - #107
Conversation
Co-authored-by: groupthinking <154503486+groupthinking@users.noreply.github.com>
…ate glob patterns Co-authored-by: groupthinking <154503486+groupthinking@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
📝 Walkthrough
WalkthroughAdded GitHub Actions automation for path-based pull request labels, automatic ChangesRepository Automation
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Warning Review ran into problems🔥 ProblemsThese MCP integrations need to be re-authenticated in the Integrations settings: Sentry Comment |
There was a problem hiding this comment.
Pull request overview
This PR adds GitHub Actions automation to the repository to (1) run a basic Node/TypeScript build on PRs and main pushes, and (2) automate labeling for PRs and newly opened issues.
Changes:
- Add a PR build workflow that runs
npm ciandnpm run build. - Add an issue-triage workflow that applies a
needs-triagelabel to new issues. - Add PR auto-labeling via
actions/labelerplus a.github/labeler.ymlruleset.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| .github/workflows/pr-checks.yml | Introduces a CI job to install dependencies and build on PRs/pushes to main. |
| .github/workflows/issue-triage.yml | Adds automation to label newly opened issues with needs-triage. |
| .github/workflows/auto-label.yml | Adds PR labeling workflow using actions/labeler (currently has a YAML issue to fix). |
| .github/labeler.yml | Defines label rules mapping file globs to labels (documentation/source/config/workflows). |
| uses: actions/labeler@v5 | ||
| with: | ||
| sync-labels: true | ||
| with: | ||
| sync-labels: true |
| - name: Checkout repository | ||
| uses: actions/checkout@v4 | ||
|
|
![coderabbitai[bot]](https://avatars.github.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/labeler.yml:
- Around line 4-26: Ensure the labels referenced by the labeler
configuration—source, config, and workflows—are available by pre-creating them
in the repository or granting the auto-label workflow issues: write permission
in .github/workflows/auto-label.yml; retain pull-requests: write as needed,
since it does not permit label creation.
In @.github/workflows/auto-label.yml:
- Around line 18-23: Remove the duplicate with mapping in the “Label PR based on
files changed” step using actions/labeler@v5, keeping a single with block
containing sync-labels: true so the workflow parses and runs correctly.
- Around line 3-19: Remove the duplicate with: mapping from the
actions/labeler@v5 step in the label job, retaining a single with: block
containing sync-labels: true so the workflow remains valid.
- Around line 18-19: Update the “Label PR based on files changed” workflow step
to use a supported major version of actions/labeler instead of v5, and pin the
action reference to its specific commit SHA rather than a mutable tag.
In @.github/workflows/issue-triage.yml:
- Line 15: Update the actions/github-script step to reference its exact commit
SHA instead of the mutable `@v7` tag, while preserving the existing workflow
behavior and permissions.
- Line 22: Create the needs-triage repository label before the
actions/github-script step that uses labels: ['needs-triage'], either by adding
it to repository settings or by bootstrapping it in the workflow. Ensure the
existing issue-triage labeling flow only calls addLabels after confirming the
label exists.
In @.github/workflows/pr-checks.yml:
- Around line 3-7: Add a workflow-level concurrency configuration to the PR
checks workflow, using a group keyed by the pull request number or ref and
enabling cancel-in-progress. Keep the existing pull_request and push triggers
unchanged so newer runs cancel only their corresponding stale builds.
- Around line 17-21: Pin every referenced third-party action to its full commit
SHA instead of mutable tags: update actions/checkout and actions/setup-node in
.github/workflows/pr-checks.yml (17-21), actions/labeler in
.github/workflows/auto-label.yml (15-19), and actions/github-script in
.github/workflows/issue-triage.yml; retain each action’s existing version as an
inline comment for traceability.
- Around line 17-18: Update the actions/checkout@v4 step in the workflow to set
persist-credentials to false, ensuring the PR-controlled npm ci and npm run
build steps cannot access persisted checkout credentials.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3c066c6d-1d8b-40ab-97f6-4a4c9a9c2091
📒 Files selected for processing (4)
.github/labeler.yml.github/workflows/auto-label.yml.github/workflows/issue-triage.yml.github/workflows/pr-checks.yml
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
groupthinking/uvai-skills(manual)
📜 Review details
⏰ Context from checks skipped due to timeout. (1)
- GitHub Check: copilot-pull-request-reviewer
🧰 Additional context used
🪛 actionlint (1.7.12)
.github/workflows/auto-label.yml
[error] 22-22: key "with" is duplicated in element of "steps" section. previously defined at line:20,col:9
(syntax-check)
🪛 YAMLlint (1.37.1)
.github/workflows/auto-label.yml
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
[error] 22-22: duplication of key "with" in mapping
(key-duplicates)
🪛 zizmor (1.26.1)
.github/workflows/issue-triage.yml
[error] 8-8: overly broad permissions (excessive-permissions): issues: write is overly broad at the workflow level
(excessive-permissions)
[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[warning] 8-8: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
[info] 11-11: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
[warning] 3-5: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
.github/workflows/pr-checks.yml
[warning] 17-18: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 21-21: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[info] 13-13: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
[warning] 3-7: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🔍 Remote MCP
Useful review context
-
PR 107 is open, currently
dirty, and changes 4 files:.github/labeler.yml,.github/workflows/auto-label.yml,.github/workflows/issue-triage.yml, and.github/workflows/pr-checks.yml(+102/−0, 5 commits, 1 existing bot comment). citeGitHub Copilot::pull_request_read::GitHub Copilot::get_comments:: -
The repo is npm/TypeScript-based:
package.jsonhasbuild: tscplusstart,dev,clean, andexamples; there is notestscript, andpackage-lock.jsonis present. citeGitHub Copilot::get_file_contents:: -
Label lookups show
documentationexists, butneeds-triage,source,config, andworkflowswere not found. The PR adds.github/labeler.ymlthat defines those label names, andissue-triage.ymladdsneeds-triage. citeGitHub Copilot::get_label::GitHub Copilot::pull_request_read:: -
The
auto-label.ymldiff includes a duplicatedwith:block under theactions/labeler@v5step. citeGitHub Copilot::pull_request_read::
🔇 Additional comments (2)
.github/workflows/pr-checks.yml (1)
20-24: 🔒 Security & PrivacyDon’t bump CI to 24.x here. This repo still documents and ships Node 18 (
DEPLOYMENT.md,Dockerfile), so changing only.github/workflows/pr-checks.ymlwould just desync CI from the actual runtime contract. If Node 18 is dead, fix the app/runtime docs and deployment image with the CI change.> Likely an incorrect or invalid review comment..github/workflows/issue-triage.yml (1)
1-8: LGTM!Also applies to: 10-14, 16-21, 23-24
| documentation: | ||
| - changed-files: | ||
| - any-glob-to-any-file: | ||
| - '*.md' | ||
| - 'docs/**' | ||
|
|
||
| source: | ||
| - changed-files: | ||
| - any-glob-to-any-file: | ||
| - 'src/**' | ||
|
|
||
| config: | ||
| - changed-files: | ||
| - any-glob-to-any-file: | ||
| - '*.json' | ||
| - '**/*.yml' | ||
| - '**/*.yaml' | ||
| - '.env*' | ||
|
|
||
| workflows: | ||
| - changed-files: | ||
| - any-glob-to-any-file: | ||
| - '.github/**' |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== .github/labeler.yml ==\n'
cat -n .github/labeler.yml
printf '\n== .github/workflows/auto-label.yml ==\n'
cat -n .github/workflows/auto-label.yml
printf '\n== label definitions in repo ==\n'
rg -n --hidden --glob '!.git' --glob '!node_modules' --glob '!dist' --glob '!build' '^(source|config|workflows):|name:\s*(source|config|workflows)\b|labels:' .github . || true
printf '\n== workflow uses of labeler/label creation ==\n'
rg -n --hidden --glob '!.git' --glob '!node_modules' 'peter-evans/create-or-update-comment|actions-ecosystem/action-add-labels|gh label|create labels|labels:' .github/workflows .github || trueRepository: groupthinking/MyXstack
Length of output: 2640
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '1,120p' .github/workflows/auto-label.yml
printf '\n---\n'
sed -n '1,120p' .github/labeler.yml
printf '\n---\n'
find .github -maxdepth 2 -type f | sortRepository: groupthinking/MyXstack
Length of output: 1241
🏁 Script executed (no clone):
#!/bin/bash
set -euo pipefail
repo='groupthinking/MyXstack'
printf '== repo labels ==\n'
curl -fsSL "https://api.github.com/repos/$repo/labels?per_page=100" | jq -r '.[].name' | sort || true
printf '\n== auto-label workflow ==\n'
curl -fsSL "https://raw.githubusercontent.com/$repo/HEAD/.github/workflows/auto-label.yml" | sed -n '1,120p' || true
printf '\n== labeler file ==\n'
curl -fsSL "https://raw.githubusercontent.com/$repo/HEAD/.github/labeler.yml" | sed -n '1,120p' || true
Length of output: 2412
🏁 Script executed:
#!/bin/bash
set -euo pipefail
nl -ba .github/workflows/auto-label.yml | sed -n '1,80p'Repository: groupthinking/MyXstack
Length of output: 200
🌐 Web query:
GitHub actions/labeler permissions issues write add labels pull request GITHUB_TOKEN
💡 Result:
The error HttpError: Resource not accessible by integration when using the GitHub labeler action is a common issue caused by the restricted permissions of the GITHUB_TOKEN when triggered by pull requests from forked repositories [1][2][3]. By design, GitHub restricts the GITHUB_TOKEN to read-only access for workflows triggered by the pull_request event originating from a fork [1][4]. This security measure prevents malicious PR authors from gaining write access to the base repository [4]. Consequently, even if you explicitly grant write permissions in your workflow, the token remains read-only for these events [3]. To resolve this issue, you should use the pull_request_target event instead of pull_request [5][1][3]. The pull_request_target event runs in the context of the base repository, which allows the GITHUB_TOKEN to have the necessary write permissions even for PRs from forks [1][3]. To correctly configure your workflow, ensure your permissions block is set to include write access for both pull-requests and issues [6][5]: permissions: contents: read pull-requests: write issues: write on: pull_request_target: types: [opened, synchronize, reopened] When using pull_request_target, exercise caution because this event has access to the repository's secrets and write permissions [7][8]. The labeler action is generally considered safe for this event because it does not execute code from the pull request, but you should always ensure your workflows are designed securely to avoid executing untrusted code [7][5]. If you still encounter permission issues within the base repository itself, ensure the job specifically includes the permissions block shown above, as the action requires write access to the issues API to manage labels [6][5].
Citations:
- 1: Labels not applied on PRs FROM forks actions/labeler#399
- 2: Warn about the limitations of GitHub tokens actions/labeler#491
- 3: https://github.com/haydenk/homestead/issues/77
- 4: starter-workflow template gives
Resource not accessible by integrationactions/labeler#12 - 5: https://github.com/marketplace/actions/labeler
- 6: HttpError: You do not have permission to create labels on this repository actions/labeler#870
- 7: https://github.com/actions/labeler?tab=readme-ov-file
- 8: https://github.com/actions/labeler/blob/main/README.md
🌐 Web query:
GitHub Actions labeler action permissions issues write pull-requests write
💡 Result:
To successfully use the GitHub Actions Labeler, you must configure appropriate permissions in your workflow file depending on your requirements [1][2][3]. Required Permissions The following permissions are recommended for the GITHUB_TOKEN to ensure the action functions correctly: permissions: contents: read pull-requests: write issues: write Breakdown of requirements: - pull-requests: write: This is required for adding existing labels to a pull request [1][2][3]. - issues: write: This is necessary if the action needs to create new labels that do not already exist in the repository [1][2][3]. If you prefer not to grant this, you must manually create all required labels in your repository before the action runs [1][2][3]. Troubleshooting Permission Issues If you encounter a Resource not accessible by integration error, it is often due to security restrictions on pull requests triggered from forked repositories [1][3][4]. By default, GitHub limits the GITHUB_TOKEN to read-only access for workflows triggered by the pull_request event from a fork [1][3][4]. To resolve this, change your workflow trigger from pull_request to pull_request_target [1][2][4]. Using pull_request_target runs the workflow in the context of the base repository and grants the GITHUB_TOKEN write access, allowing the labeler to function correctly [1][3][4]. Note that you should exercise caution when using pull_request_target, as it executes with the permissions of the base repository and can access repository secrets [3]. Ensure your workflow is designed to avoid executing untrusted code from the fork [1][3].
Citations:
- 1: https://github.com/actions/labeler?tab=readme-ov-file
- 2: https://github.com/actions/labeler/blob/main/README.md
- 3: https://github.com/marketplace/actions/labeler
- 4: Labels not applied on PRs FROM forks actions/labeler#399
🌐 Web query:
site:docs.github.com actions/labeler permissions pull-requests write issues write
💡 Result:
When using the official actions/labeler action in a GitHub Actions workflow, the necessary permissions depend on the objects you are labeling. Because GitHub treats pull requests as a type of issue in its API, the GITHUB_TOKEN requires the issues: write permission to apply labels to issues and the pull-requests: write permission to apply labels to pull requests [1][2]. Specifically, if you are configuring a workflow to label pull requests, you must include the following permissions in your job configuration [1][2]: permissions: pull-requests: write contents: read If your workflow also needs to label issues, you must add the issues: write permission [3][4]: permissions: issues: write pull-requests: write contents: read It is a security best practice to explicitly define these permissions in your workflow file rather than relying on default settings, as this adheres to the principle of least privilege [5][6]. When the permissions key is explicitly defined, all unspecified permissions are set to no access (with the exception of metadata, which is always granted read access) [6].
Citations:
- 1: https://docs.github.com/en/enterprise-server@3.4/actions/security-guides/automatic-token-authentication
- 2: https://docs.github.com/en/enterprise-server@3.2/actions/reference/authentication-in-a-workflow
- 3: https://docs.github.com/actions/guides/adding-labels-to-issues
- 4: https://docs.github.com/en/enterprise-server@3.4/actions/managing-issues-and-pull-requests/adding-labels-to-issues
- 5: https://docs.github.com/actions/reference/authentication-in-a-workflow
- 6: https://docs.github.com/en/enterprise-server@3.13/actions/security-guides/automatic-token-authentication
Add the missing repo labels or grant label-creation access. source, config, and workflows are referenced in .github/labeler.yml, but they don’t exist in the repo. actions/labeler won’t apply them unless you pre-create them or add issues: write; pull-requests: write alone doesn’t cover label creation.
📍 Affects 2 files
.github/labeler.yml#L4-L26(this comment).github/workflows/auto-label.yml#L7-L9
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/labeler.yml around lines 4 - 26, Ensure the labels referenced by the
labeler configuration—source, config, and workflows—are available by
pre-creating them in the repository or granting the auto-label workflow issues:
write permission in .github/workflows/auto-label.yml; retain pull-requests:
write as needed, since it does not permit label creation.
Source: MCP tools
| on: | ||
| pull_request: | ||
| types: [opened, edited, synchronize] | ||
|
|
||
| permissions: | ||
| contents: read | ||
| pull-requests: write | ||
|
|
||
| jobs: | ||
| label: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Label PR based on files changed | ||
| uses: actions/labeler@v5 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- .github/workflows/auto-label.yml ---'
cat -n .github/workflows/auto-label.ymlRepository: groupthinking/MyXstack
Length of output: 781
Remove the duplicate with: block. There are two with: mappings under actions/labeler@v5; keep one sync-labels: true block or the workflow becomes invalid.
🧰 Tools
🪛 YAMLlint (1.37.1)
[warning] 3-3: truthy value should be one of [false, true]
(truthy)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/auto-label.yml around lines 3 - 19, Remove the duplicate
with: mapping from the actions/labeler@v5 step in the label job, retaining a
single with: block containing sync-labels: true so the workflow remains valid.
| - name: Label PR based on files changed | ||
| uses: actions/labeler@v5 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '--- workflow ---\n'
cat -n .github/workflows/auto-label.yml
printf '\n--- labeler references ---\n'
rg -n "actions/labeler|labeler@v|node 20|node20|pin" .github/workflows .github -S || trueRepository: groupthinking/MyXstack
Length of output: 251
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- .github/workflows/auto-label.yml ---'
cat -n .github/workflows/auto-label.yml
echo
echo '--- references under .github ---'
rg -n "actions/labeler|labeler@v|node 20|node20|commit SHA|sha" .github -S || trueRepository: groupthinking/MyXstack
Length of output: 973
🌐 Web query:
GitHub actions/labeler v5 Node.js 20 runtime EOL v6 supported major
💡 Result:
The actions/labeler GitHub Action has progressed beyond version 5 [1]. Version 5 of the action utilized the Node.js 20 runtime [2][3]. As of today, July 24, 2026, version 6 of actions/labeler is available and fully supported [4][1]. This version upgraded the underlying runtime from Node.js 20 to Node.js 24 [4][5]. Regarding the Node.js 20 runtime environment on GitHub Actions: - Node.js 20 reached its end-of-life (EOL) in April 2026 [6]. - GitHub began the deprecation process for Node.js 20 on GitHub Actions runners following its EOL [6]. - While Node.js 24 has become the default runtime for GitHub Actions runners as of June 16, 2026, users were provided options to temporarily continue using Node.js 20 via environment variables (such as ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true) until the runtime is fully removed from runners in the fall of 2026 [6]. It is recommended to use the latest version of actions/labeler (currently v7.0.0 is available) or at least a version within the v6 series to ensure compatibility with modern Node.js runtimes [4][1].
Citations:
- 1: https://github.com/actions/labeler/releases
- 2: https://github.com/actions/labeler?tab=readme-ov-file
- 3: https://github.com/actions/labeler/releases/tag/v5.0.0
- 4: https://github.com/actions/labeler/releases/tag/v6.0.0
- 5: actions/labeler@v5.0.0...main
- 6: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
Upgrade actions/labeler off v5. It runs on Node 20, which is already EOL. Move to a supported major and pin it to a commit SHA.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/auto-label.yml around lines 18 - 19, Update the “Label PR
based on files changed” workflow step to use a supported major version of
actions/labeler instead of v5, and pin the action reference to its specific
commit SHA rather than a mutable tag.
| - name: Label PR based on files changed | ||
| uses: actions/labeler@v5 | ||
| with: | ||
| sync-labels: true | ||
| with: | ||
| sync-labels: true |
There was a problem hiding this comment.
🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '1,120p' .github/workflows/auto-label.yml | cat -nRepository: groupthinking/MyXstack
Length of output: 740
Remove the duplicate with mapping. This step defines with twice, which breaks the workflow parser and stops actions/labeler@v5 from running. Keep only one with block.
🧰 Tools
🪛 actionlint (1.7.12)
[error] 22-22: key "with" is duplicated in element of "steps" section. previously defined at line:20,col:9
(syntax-check)
🪛 YAMLlint (1.37.1)
[error] 22-22: duplication of key "with" in mapping
(key-duplicates)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/auto-label.yml around lines 18 - 23, Remove the duplicate
with mapping in the “Label PR based on files changed” step using
actions/labeler@v5, keeping a single with block containing sync-labels: true so
the workflow parses and runs correctly.
Source: Linters/SAST tools
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Add triage label to new issues | ||
| uses: actions/github-script@v7 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## issue-triage.yml\n'
cat -n .github/workflows/issue-triage.yml | sed -n '1,120p'
printf '\n## pinning policy search\n'
rg -n --hidden --glob '!.git' -e 'pinning|sha pin|commit sha|immutable action|actions/.*`@v`[0-9]+' .github .github/workflows README* docs* . || trueRepository: groupthinking/MyXstack
Length of output: 1991
Pin actions/github-script to a commit SHA.
actions/github-script@v7 is mutable; it can change under the same version tag while this workflow still has issues: write. Lock it to the exact commit SHA.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/issue-triage.yml at line 15, Update the
actions/github-script step to reference its exact commit SHA instead of the
mutable `@v7` tag, while preserving the existing workflow behavior and
permissions.
Source: Linters/SAST tools
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: context.payload.issue.number, | ||
| labels: ['needs-triage'] |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## files mentioning needs-triage\n'
rg -n --hidden --glob '!**/.git/**' 'needs-triage' .
printf '\n## issue-triage workflow\n'
sed -n '1,220p' .github/workflows/issue-triage.yml
printf '\n## label-related config files\n'
fd -a -t f '.github' .Repository: groupthinking/MyXstack
Length of output: 829
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## workflow outline/config references\n'
rg -n --hidden --glob '!**/.git/**' 'createLabel|labels:|issues\.labels|labeler|needs-triage' .github . || true
printf '\n## repository label definitions/configuration files\n'
fd -a -t f .github .Repository: groupthinking/MyXstack
Length of output: 1022
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## issue-triage workflow\n'
cat -n .github/workflows/issue-triage.yml
printf '\n## labeler config\n'
if [ -f .github/labeler.yml ]; then
cat -n .github/labeler.yml
fi
printf '\n## label files at repo root or .github\n'
find . -maxdepth 2 \( -name '*.yml' -o -name '*.yaml' \) | sortRepository: groupthinking/MyXstack
Length of output: 1622
🌐 Web query:
GitHub REST API add labels to issue missing label behavior 404 422 repository labels
💡 Result:
When using the GitHub REST API to add labels to an issue via the POST /repos/{owner}/{repo}/issues/{issue_number}/labels endpoint, the behavior regarding non-existent labels and error status codes is as follows: HTTP 404 (Not Found): This status is typically returned if the repository, issue, or the specified endpoint path does not exist [1][2][3]. HTTP 422 (Validation Failed): If you attempt to add a label that does not already exist in the repository, this endpoint will typically return a 422 error [1][2][4]. The API expects the labels provided in the request body to already be defined within the repository's label set [1][3]. If a label is missing, the request fails validation because it cannot associate a non-existent label with the issue [1][2]. Regarding "missing label" behavior: - Adding labels: You must ensure the labels exist in the repository before attempting to add them to an issue [1][3]. If they do not exist, you must create them first using the POST /repos/{owner}/{repo}/labels endpoint [3]. - Removing labels: If you attempt to use the DELETE /repos/{owner}/{repo}/issues/{issue_number}/labels/{name} endpoint to remove a label that is not currently applied to the issue, it will return a 404 Not Found status [5][3]. Note: Documentation for these endpoints can sometimes contain inaccuracies regarding input validation [6], but the requirement that labels must exist before being added to an issue is standard behavior [1][3]. Always verify that your labels are created in the repository prior to assigning them to an issue [3].
Citations:
- 1: https://docs.github.com/en/rest/issues/labels
- 2: https://docs.github.com/en/enterprise-server@3.19/rest/issues/labels
- 3: https://docs.github.com/en/enterprise-server@3.21/rest/issues/labels?apiVersion=2026-03-10
- 4: https://docs.github.com/en/enterprise-server@3.20/rest/issues/labels?apiVersion=2022-11-28
- 5: https://docs.github.com/en/enterprise-server@3.18/rest/issues/labels
- 6: [Schema Inaccuracy] "Add labels to an issue" requestBody and description incorrect github/rest-api-description#3366
🌐 Web query:
"GitHub issues.addLabels missing labels ignored" "GitHub REST API"
💡 Result:
When using the GitHub REST API to add labels to an issue, the API requires that the labels already exist in the repository [1][2]. If you attempt to add a label that has not been previously created in the repository, the GitHub API will typically ignore that specific label or return an error, rather than automatically creating it for you [3]. Key points regarding this behavior: 1. Requirement of Pre-existence: The POST /repos/{owner}/{repo}/issues/{issue_number}/labels endpoint is designed to associate existing repository labels with an issue [1][4]. It does not have the functionality to create new labels on the fly [1][2]. 2. Silent Drops or Failures: In many contexts, such as when creating a new issue with a list of labels, GitHub will silently drop labels that do not exist or for which the user lacks sufficient permissions [5][3]. If you are using libraries like Octokit, note that the library does not automatically create missing labels; you must ensure the labels exist in the repository before referencing them in your API calls [3]. 3. Recommended Workflow: To add a label that may not exist, you should first check for its existence or attempt to create it using the POST /repos/{owner}/{repo}/labels endpoint. Only after verifying or creating the label should you proceed to add it to the issue [6][4]. If you find that labels are being ignored, ensure that the label name is spelled exactly as it appears in the repository (GitHub labels are case-sensitive) and that your API token or GitHub App has the necessary permissions to manage labels [5][3].
Citations:
- 1: https://docs.github.com/en/enterprise-cloud@latest/rest/issues/labels
- 2: https://docs.github.com/rest/issues/labels
- 3: [BUG]: New label is not created on creating a new github issue octokit/rest.js#479
- 4: https://docs.github.com/en/rest/issues/labels
- 5: https://docs.github.com/en/rest/issues/issues
- 6: https://docs.github.com/rest/reference/issues
Create needs-triage before using it here.
actions/github-script only adds existing repo labels. needs-triage isn’t defined anywhere in this repo, so every new issue will trip a failing addLabels call until the label exists. Add it in repo settings or bootstrap it in the workflow first.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/issue-triage.yml at line 22, Create the needs-triage
repository label before the actions/github-script step that uses labels:
['needs-triage'], either by adding it to repository settings or by bootstrapping
it in the workflow. Ensure the existing issue-triage labeling flow only calls
addLabels after confirming the label exists.
Source: MCP tools
| on: | ||
| pull_request: | ||
| branches: [main] | ||
| push: | ||
| branches: [main] |
There was a problem hiding this comment.
🚀 Performance & Scalability | 🔵 Trivial
Cancel stale PR builds.
Every synchronization event can leave older npm ci and TypeScript builds running after a newer commit arrives. Add a concurrency group keyed by PR number or ref so stale work is cancelled instead of consuming runners and producing obsolete checks.
As per static analysis, zizmor reports missing concurrency limits. GitHub documents concurrency with cancel-in-progress for this case. (docs.github.com)
Proposed fix
on:
pull_request:
branches: [main]
push:
branches: [main]
+concurrency:
+ group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
+ cancel-in-progress: true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: | |
| pull_request: | |
| branches: [main] | |
| push: | |
| branches: [main] | |
| on: | |
| pull_request: | |
| branches: [main] | |
| push: | |
| branches: [main] | |
| concurrency: | |
| group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} | |
| cancel-in-progress: true |
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 3-7: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/pr-checks.yml around lines 3 - 7, Add a workflow-level
concurrency configuration to the PR checks workflow, using a group keyed by the
pull request number or ref and enabling cancel-in-progress. Keep the existing
pull_request and push triggers unchanged so newer runs cancel only their
corresponding stale builds.
Source: Linters/SAST tools
| - name: Checkout repository | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
git ls-files .github/workflows/pr-checks.yml
echo '---'
cat -n .github/workflows/pr-checks.ymlRepository: groupthinking/MyXstack
Length of output: 884
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
p = Path('.github/workflows/pr-checks.yml')
print(p.exists())
if p.exists():
print(p.read_text())
PYRepository: groupthinking/MyXstack
Length of output: 644
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '1,120p' .github/workflows/pr-checks.yml | cat -nRepository: groupthinking/MyXstack
Length of output: 848
Disable persisted checkout creds. .github/workflows/pr-checks.yml:17-18 runs PR-controlled npm ci and npm run build right after checkout, and actions/checkout leaves the token in git config by default. Set persist-credentials: false; nothing here needs authenticated git access.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 17-18: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/pr-checks.yml around lines 17 - 18, Update the
actions/checkout@v4 step in the workflow to set persist-credentials to false,
ensuring the PR-controlled npm ci and npm run build steps cannot access
persisted checkout credentials.
Source: MCP tools
| - name: Checkout repository | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup Node.js | ||
| uses: actions/setup-node@v4 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## .github/workflows/pr-checks.yml\n'
cat -n .github/workflows/pr-checks.yml
printf '\n## .github/workflows/auto-label.yml\n'
cat -n .github/workflows/auto-label.yml
printf '\n## action refs across workflows\n'
rg -n 'uses:\s*[^@]+@' .github/workflows -g '*.yml' -g '*.yaml'Repository: groupthinking/MyXstack
Length of output: 1890
Pin the workflow actions to commit SHAs. actions/checkout, actions/setup-node, actions/labeler, and actions/github-script are all on mutable tags here, so the code you run can drift without any repo diff. Lock them to full commit SHAs in .github/workflows/pr-checks.yml, .github/workflows/auto-label.yml, and .github/workflows/issue-triage.yml.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 17-18: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 21-21: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
📍 Affects 2 files
.github/workflows/pr-checks.yml#L17-L21(this comment).github/workflows/auto-label.yml#L15-L19
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/pr-checks.yml around lines 17 - 21, Pin every referenced
third-party action to its full commit SHA instead of mutable tags: update
actions/checkout and actions/setup-node in .github/workflows/pr-checks.yml
(17-21), actions/labeler in .github/workflows/auto-label.yml (15-19), and
actions/github-script in .github/workflows/issue-triage.yml; retain each
action’s existing version as an inline comment for traceability.
|
Do not resolve the conflicts on this PR. Re-cut the branch from current I audited all five open PRs (#106–#110) against the GitHub compare API. Every one of them is a long-stale branch, not a genuine content conflict:
All five report Why the diffs look absurd#109 is titled "fix: replace invalid CODEOWNERS entries with @groupthinking" but reports +30,880 / −216 across 38 files, with essentially every file showing That is not what the PR intends to change. The branch was cut on 2026-01-27 and opened as a PR on 2026-07-24 — a six-month gap during which The conflicts are therefore real, but they are drift, not disagreement. Resolving them by hand means manually reconciling six months of divergence across 38 files to land what should be a handful of line edits — and every manual resolution is an opportunity to silently revert work that landed on ResolutionFor each PR, the actual intent is small and is captured in only 1–12 commits. Re-apply that intent on top of current git fetch origin
git checkout -b <name>-rebased origin/main
git cherry-pick <the 1-12 real commits> # or simply re-make the edit by handThen open a replacement PR and close the stale one. For #109 specifically, the intended change is a CODEOWNERS edit — that is a few lines, and re-making it by hand against current Recommended disposition:
Root cause to fix going forward: these five PRs were all opened within a 112-second window (22:41:30 → 22:43:22 on 2026-07-24) from branches that were months old. Whatever automation opened them did not rebase first. Adding a staleness check — refuse to open a PR whose branch is more than N commits behind its base — would prevent this class of PR entirely. |
No description provided.