Skip to content

chore(deps): bump tj-actions/changed-files from 47.0.5 to 47.0.6 #344

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.

Sign up for GitHub

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

Open
dependabot wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps): bump tj-actions/changed-files from 47.0.5 to 47.0.6 #344

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/auto-label.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,13 +15,13 @@
steps:
- name: Checkout
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

- name: Get changed files
id: changed-files
uses: tj-actions/changed-files@22103cc46bda19c2b464ffe86db46df6922fd323 # v47.0.5
uses: tj-actions/changed-files@9426d40962ed5378910ee2e21d5f8c6fcbf2dd96 # v47.0.6

Check notice on line 21 in .github/workflows/auto-label.yml

View check run for this annotation

Claude / Claude Code Review

Missing github-actions label causes Dependabot PRs to fail labeling 

This is a pre-existing issue: `.github/dependabot.yml` specifies the `github-actions` label for the github-actions package ecosystem, but this label does not exist in the repository. The `auto-label.yml` workflow's color map (which drives auto-creation) also does not include `github-actions`, so the label is never created — causing every Dependabot GitHub Actions PR (including this one) to emit the error: *'The following labels could not be found: github-actions'*. Fix: add `'github-actions': 'X
Comment on lines 18 to +21
Copy link
Copy Markdown

@claude claude Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟣 This is a pre-existing issue: .github/dependabot.yml specifies the github-actions label for the github-actions package ecosystem, but this label does not exist in the repository. The auto-label.yml workflow's color map (which drives auto-creation) also does not include github-actions, so the label is never created — causing every Dependabot GitHub Actions PR (including this one) to emit the error: 'The following labels could not be found: github-actions'. Fix: add 'github-actions': 'XXXXXX' to the colors map in auto-label.yml so the label is auto-created when needed, or manually create the label in the repo settings.

Extended reasoning...

What the bug is and how it manifests

The .github/dependabot.yml configuration specifies labels: ['dependencies', 'github-actions'] for the github-actions package ecosystem (line 53). When Dependabot opens a PR for a GitHub Actions dependency bump, it attempts to attach both labels. The github-actions label does not exist in the repository, so Dependabot cannot apply it and emits an error comment instead.

The specific code path that triggers it

Dependabot reads dependabot.yml when creating the PR and calls the GitHub Labels API to add the listed labels. When github-actions is not found, the API returns a 404/422 error and Dependabot posts the error comment visible in this PR's timeline: 'The following labels could not be found: github-actions. Please create it before Dependabot can add it to a pull request.'

Why existing code doesn't prevent it

The auto-label.yml workflow (modified in this PR) has a colors map that lists every label it may need to auto-create: core, documentation, ci/cd, security, config, tests, enhancement, bug, chore, refactor, performance, breaking-change, devops, dependencies, candidate-release. The label github-actions is absent from this map. Even if the auto-label workflow ran first, it would never create the github-actions label. Furthermore, the auto-label workflow runs after PR creation via pull_request: opened — by which point Dependabot has already attempted and failed to apply its labels.

Impact

Every Dependabot PR that bumps a GitHub Actions dependency (e.g., this PR and all future github-actions ecosystem bumps) will have a permanent error comment from Dependabot and will be missing the intended github-actions label. This is noise in the PR timeline and breaks intended labeling/filtering workflows.

How to fix it

Add 'github-actions': '2088FF' (or any appropriate color) to the colors object inside the auto-label.yml script block. This ensures the label is auto-created by the workflow when needed. Alternatively, manually create the github-actions label in the GitHub repository settings, or update dependabot.yml to reference only existing labels.

Step-by-step proof

  1. Dependabot reads .github/dependabot.yml and finds the github-actions ecosystem entry with labels: ['dependencies', 'github-actions'].
  2. Dependabot opens this PR (chore(deps): bump tj-actions/changed-files from 47.0.5 to 47.0.6).
  3. Dependabot calls the GitHub Labels API to attach dependencies and github-actions to the PR.
  4. dependencies exists (it is in the auto-label color map and has been created), so it applies successfully.
  5. github-actions does not exist in the repo — the API call fails.
  6. Dependabot posts the error comment at 2026-04-20T11:41:29Z: 'The following labels could not be found: github-actions.'
  7. The auto-label.yml workflow runs on PR open/sync, but its color map has no entry for github-actions, so it never creates the label either.

with:
files_yaml: |
src:

Check notice on line 24 in .github/workflows/auto-label.yml

View check run for this annotation

Claude / Claude Code Review

Catch block in label creation does not check error type 

**Pre-existing issue:** The label existence check in `.github/workflows/auto-label.yml` uses a bare `catch (e)` block without checking `e.status === 404`, meaning any transient error (rate limit 429, permission error 403, server error 500) from `getLabel` will incorrectly trigger a `createLabel` call. The fix is to rethrow non-404 errors: `catch (e) { if (e.status \!== 404) throw e; ... createLabel ... }`.
Comment on lines 22 to 24
Copy link
Copy Markdown

@claude claude Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟣 Pre-existing issue: The label existence check in .github/workflows/auto-label.yml uses a bare catch (e) block without checking e.status === 404, meaning any transient error (rate limit 429, permission error 403, server error 500) from getLabel will incorrectly trigger a createLabel call. The fix is to rethrow non-404 errors: catch (e) { if (e.status \!== 404) throw e; ... createLabel ... }.

Extended reasoning...

Bug description: In .github/workflows/auto-label.yml, the label creation loop checks for label existence using a try/catch pattern. However, the catch block does not inspect the error status code before attempting to create the label. The pattern is:

try {
  await github.rest.issues.getLabel({ owner, repo, name: label });
} catch (e) {
  // Create label if it doesn't exist
  await github.rest.issues.createLabel({ ... });
}

How it manifests: The catch block is only intended to handle HTTP 404 (Not Found) errors — i.e., when the label does not yet exist. But since there is no e.status === 404 guard, any error from getLabel falls into this branch, including HTTP 429 (rate limit exceeded), 403 (insufficient permissions), 500 (GitHub server error), or transient network failures.

Specific code path: When github.rest.issues.getLabel throws a non-404 error (e.g., because the workflow token has hit a rate limit), execution falls into the catch block and immediately attempts github.rest.issues.createLabel. If the label already exists, createLabel will throw a 422 Unprocessable Entity error (label already exists), which propagates out and causes the workflow step to fail with a confusing, misleading error message. If the label doesn't yet exist, the createLabel call might also fail under the same transient condition, producing an unhelpful secondary error.

Why existing code doesn't prevent it: There is no inner try/catch around createLabel, and there is no e.status check in the outer catch. The comment // Create label if it doesn't exist signals the developer's intent, but the code does not enforce it.

Impact: During periods of GitHub API instability or rate limiting, the auto-label workflow can fail with a 422 error on createLabel for labels that actually do exist. This wastes API quota, produces misleading CI failure messages, and could block PR labeling for all labels in the batch.

Concrete proof (step-by-step):

  1. PR is opened, triggering the auto-label workflow.
  2. GitHub is currently rate-limiting this token (429 response).
  3. getLabel({ name: 'ci/cd' }) throws with e.status === 429.
  4. The catch block runs with no status check; createLabel({ name: 'ci/cd', ... }) is called.
  5. The ci/cd label already exists, so GitHub returns 422 Unprocessable Entity.
  6. The 422 error propagates, failing the workflow step with a confusing message about label creation rather than the real cause (rate limiting).

Fix: Add a status check at the start of the catch block:

} catch (e) {
  if (e.status \!== 404) throw e;
  // Create label if it doesn't exist
  await github.rest.issues.createLabel({ ... });
}

Note: This is a pre-existing issue unrelated to this PR's change (bumping tj-actions/changed-files from v47.0.5 to v47.0.6). The PR touches this file but does not interact with the label creation logic.

- 'src/**'
docs:
- 'docs/**'
Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/docs-check.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,13 +19,13 @@
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
with:
fetch-depth: 0

- name: Get changed files
id: changed-files
uses: tj-actions/changed-files@22103cc46bda19c2b464ffe86db46df6922fd323 # v47.0.5
uses: tj-actions/changed-files@9426d40962ed5378910ee2e21d5f8c6fcbf2dd96 # v47.0.6
with:
files_yaml: |
src:

Check notice on line 28 in .github/workflows/docs-check.yml

View check run for this annotation

Claude / Claude Code Review

docs-check.yml: path trigger and skip-check mechanism are both broken 

This is a pre-existing issue: the docs-check.yml workflow has two related logic bugs that render the documentation check completely non-functional. The on.pull_request.paths trigger only watches docs/**, README.md, and CHANGELOG.md — it never fires for src-only PRs, so the check-docs-updated job can never warn about missing documentation for source changes. Additionally, adding [skip-docs-check] to the PR title does not suppress the warning because the warning step runs before the skip step, emi
Comment on lines 22 to 28
Copy link
Copy Markdown

@claude claude Bot Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟣 This is a pre-existing issue: the docs-check.yml workflow has two related logic bugs that render the documentation check completely non-functional. The on.pull_request.paths trigger only watches docs/**, README.md, and CHANGELOG.md — it never fires for src-only PRs, so the check-docs-updated job can never warn about missing documentation for source changes. Additionally, adding [skip-docs-check] to the PR title does not suppress the warning because the warning step runs before the skip step, emitting the annotation regardless.

Extended reasoning...

Bug 1: Inverted path trigger renders the docs check dead for its intended use case

The docs-check.yml workflow fires on pull_request events only when files matching docs/, README.md, or CHANGELOG.md are changed (lines 6-9). However, the entire purpose of the check-docs-updated job is to warn when src//*.ts files are modified WITHOUT corresponding documentation updates. This is logically inverted: the workflow only triggers when docs are changed, but the check is supposed to fire when docs are not changed alongside src. As a result, any PR that changes only source code files will not trigger this workflow at all — the safety net silently disappears for exactly the PRs it is meant to catch.

Concrete proof of Bug 1: Consider a PR that modifies src/commands/run.ts but no documentation files. The on.pull_request.paths filter does not match — the workflow is never queued. The developer receives no warning. The check-docs-updated job's condition (steps.changed-files.outputs.src_any_changed == 'true') is never evaluated. The only scenario where the workflow triggers AND the warning could theoretically fire requires both src and docs to be changed simultaneously — but in that case docs_any_changed would be 'true', meaning the condition docs_any_changed != 'true' is false and the warning branch is skipped anyway. The fix is to add - 'src/**/*.ts' to the on.pull_request.paths list.

Bug 2: Step ordering makes [skip-docs-check] ineffective

The check-docs-updated step at line 35 has if: steps.changed-files.outputs.src_any_changed == 'true' but no condition checking the PR title. The shell script inside unconditionally emits echo '::warning::...' when docs were not updated. The skip-check-if-marked step at line 54 runs afterward and only prints a message — it cannot retroactively suppress a ::warning:: annotation already emitted to the GitHub Actions log. Users who add [skip-docs-check] to their PR title will still see the warning annotation, followed by a misleading 'Documentation check skipped via PR title.' message. The user expectation (skip suppresses the warning) is never met.

Concrete proof of Bug 2: A PR titled 'fix: update parser logic [skip-docs-check]' changes src/parser.ts but no docs. Step 1 (line 35) runs because src_any_changed is 'true'; it echoes ::warning::Source code was changed but no documentation was updated. into the log. Step 2 (line 54) runs because the title contains '[skip-docs-check]'; it echoes 'Documentation check skipped via PR title.' — but the warning is already in the annotations panel. The skip mechanism provides false assurance. The fix is to add && !contains(github.event.pull_request.title, '[skip-docs-check]') to the if condition of the warning step at line 36.

Addressing the duplicate objection for Bug 1: One verifier noted bug_003 may duplicate bug_001. The synthesis agent explicitly merged both bugs (bug_003 and bug_005) into this combined merged_bug_003 because they are two distinct but related logic errors in the same job — the path trigger inversion and the step-ordering skip failure. Even if the path trigger issue overlaps with bug_001, the skip-mechanism ordering bug (bug_005) is a separate and independent defect that this merged report covers. The combined report is therefore not a pure duplicate.

Impact and context: Both bugs are pre-existing — this PR only version-bumps tj-actions/changed-files from 47.0.5 to 47.0.6 — but the PR does touch docs-check.yml, making this the right moment to flag them. The practical impact is that source code changes can silently merge without documentation updates, and the [skip-docs-check] escape hatch misleads contributors into thinking their warning was suppressed when it was not.

- 'src/**/*.ts'
docs:
- 'README.md'
Expand Down
Loading