@htekdev/actions-debugger 1.0.99 → 1.0.101

package/errors/caching-artifacts/caching-artifacts-055.yml

@@ -0,0 +1,104 @@
+id: caching-artifacts-055
+title: 'setup-python cache: poetry broken when poetry is installed before setup-python — virtualenv 20.33.0+ Python version mismatch'
+category: caching-artifacts
+severity: error
+tags:
+  - setup-python
+  - poetry
+  - cache
+  - virtualenv
+  - python-version
+  - pipx
+  - ordering
+patterns:
+  - regex: 'Current Python version \([\d.]+\) is not allowed by the project'
+    flags: 'i'
+  - regex: 'poetry.*install.*exit code 1'
+    flags: 'i'
+  - regex: 'Please change python executable via the "env use" command'
+    flags: 'i'
+  - regex: 'installed package poetry.*using Python \d+\.\d+'
+    flags: 'i'
+error_messages:
+  - "Current Python version (3.12.3) is not allowed by the project (>= 3.13, < 4). Please change python executable via the \"env use\" command."
+  - "Current Python version (3.11.9) is not allowed by the project (>=3.12,<3.13). Please change python executable via the \"env use\" command."
+  - "Error: Process completed with exit code 1."
+root_cause: |
+  When using actions/setup-python with cache: 'poetry', the action requires
+  poetry to be installed BEFORE it runs (to resolve the cache path). Developers
+  commonly install poetry via pipx before calling setup-python, which causes
+  pipx to anchor poetry to the runner's pre-installed system Python (e.g., 3.12.3).
+
+  After setup-python runs and installs the project's target Python version
+  (e.g., 3.13), poetry's internal virtualenv logic still references the Python
+  version it was originally installed with. Consequently, when poetry creates
+  or activates a virtual environment, it resolves to the old Python version —
+  which violates the project's python requirement and produces the
+  "Current Python version is not allowed" error.
+
+  This became a consistent failure in August 2025 when virtualenv 20.33.0
+  changed how it resolves the Python interpreter for new virtual environments,
+  making the version mismatch explicit and fatal rather than silently using
+  the wrong interpreter.
+
+  The fundamental issue is a circular dependency in the documented workflow:
+  setup-python needs poetry installed to set up caching, but poetry must be
+  installed after setup-python to use the correct Python version.
+fix: |
+  Use actions/cache manually instead of setup-python's built-in poetry cache.
+  Install poetry AFTER setup-python so it is anchored to the correct Python.
+  This avoids the circular ordering problem entirely.
+fix_code:
+  - language: yaml
+    label: 'Workaround — Manual cache + install poetry after setup-python'
+    code: |
+      steps:
+        - uses: actions/setup-python@v5
+          id: setup-python
+          with:
+            python-version: '3.13'
+            # Do NOT use cache: 'poetry' here
+
+        - name: Install poetry
+          run: pipx install poetry
+
+        - name: Cache poetry virtualenv
+          uses: actions/cache@v4
+          with:
+            path: ~/.cache/pypoetry/virtualenvs
+            key: ${{ runner.os }}-poetry-${{ steps.setup-python.outputs.python-version }}-${{ hashFiles('**/poetry.lock') }}
+            restore-keys: |
+              ${{ runner.os }}-poetry-${{ steps.setup-python.outputs.python-version }}-
+
+        - name: Install dependencies
+          run: poetry install
+  - language: yaml
+    label: 'Alternative — pin virtualenv version as a short-term patch'
+    code: |
+      steps:
+        - name: Install poetry (with pinned virtualenv)
+          run: |
+            pipx install poetry
+            pipx inject poetry virtualenv==20.26.6
+
+        - uses: actions/setup-python@v5
+          with:
+            python-version: '3.13'
+            cache: 'poetry'
+
+        - name: Install dependencies
+          run: poetry install
+prevention:
+  - "Never use setup-python cache: poetry in combination with a poetry install step that runs before setup-python."
+  - "Use actions/cache manually to avoid the circular dependency between poetry installation and Python version resolution."
+  - "Keep poetry updated — poetry 2.1.4+ partially mitigates the virtualenv version mismatch for some project configurations."
+  - "Use uv as an alternative to poetry; uv is installed on GitHub-hosted runners and handles Python version resolution differently."
+docs:
+  - url: 'https://github.com/actions/setup-python/issues/1167'
+    label: 'actions/setup-python #1167 — Issues with poetry caching (Aug 2025)'
+  - url: 'https://github.com/python-poetry/poetry/issues/10490'
+    label: 'python-poetry/poetry #10490 — virtualenv 20.33.0 compatibility issue'
+  - url: 'https://github.com/pypa/virtualenv/issues/2931'
+    label: 'pypa/virtualenv #2931 — Python interpreter resolution change'
+  - url: 'https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#caching-packages'
+    label: 'actions/setup-python — Caching packages documentation'

package/errors/caching-artifacts/caching-artifacts-056.yml

@@ -0,0 +1,113 @@
+id: caching-artifacts-056
+title: 'actions/cache v1 and v2 deprecated — workflows fail hard with "automatically failed" error'
+category: caching-artifacts
+severity: error
+tags:
+  - actions/cache
+  - deprecated
+  - v1
+  - v2
+  - hard-failure
+  - breaking-change
+  - upgrade
+patterns:
+  - regex: 'automatically failed.*deprecated version.*actions/cache'
+    flags: 'i'
+  - regex: 'deprecated version of.{0,30}actions/cache'
+    flags: 'i'
+  - regex: 'actions/cache@v[12]\b'
+    flags: 'i'
+error_messages:
+  - "This request has been automatically failed because it uses a deprecated version of `actions/cache: 6849a6489940f00c2f30c0fb92c6274307ccb58a`"
+  - "Error: This request has been automatically failed because it uses a deprecated version of `actions/cache`"
+root_cause: |
+  GitHub announced in December 2024 (GitHub Changelog) that `actions/cache` versions 1 and 2
+  were deprecated and would be hard-failed starting February 1, 2025. Any workflow still
+  pinned to `actions/cache@v1` or `actions/cache@v2` (or to a full SHA that resolves to
+  those versions) now fails immediately with a hard error — no cache operation is attempted
+  and the entire step fails.
+
+  The error message includes the SHA of the deprecated action version:
+    "This request has been automatically failed because it uses a deprecated version
+    of `actions/cache: <SHA>`"
+
+  This is a hard failure, not a graceful degradation — the step exit code is non-zero and
+  causes the job to fail unless `continue-on-error: true` is set on the step (which is
+  not a recommended fix).
+
+  Common reasons workflows are still on v1/v2:
+  1. The workflow was written years ago and never updated
+  2. The action is referenced by a full commit SHA from before v3 was released
+  3. A reusable workflow or composite action calls an outdated dependency that pins v1/v2
+  4. `Dependabot` is not enabled on the repo for GitHub Actions
+
+  Note: `actions/cache@v3` and `actions/cache@v4` are both supported. V4 is the current
+  recommended version.
+fix: |
+  Upgrade all `actions/cache` references from v1 or v2 to v4 (recommended) or v3.
+  Search your repository for `actions/cache@v1` and `actions/cache@v2` references,
+  including in nested composite actions and reusable workflows.
+
+  If you are migrating from v3 to v4, note the breaking changes documented in the
+  v3-to-v4 migration guide (see caching-artifacts-009). The v1/v2 to v4 migration
+  follows the same v3-to-v4 guidance since v3 and v4 share the same input API except
+  for `save-always`.
+
+  Enable Dependabot for GitHub Actions updates to automatically receive future
+  deprecation PRs.
+fix_code:
+  - language: yaml
+    label: 'Problem: workflow pinned to deprecated actions/cache v1 or v2'
+    code: |
+      steps:
+        - uses: actions/checkout@v4
+
+        # FAILS: v1 and v2 are deprecated — hard failure since Feb 1, 2025
+        - uses: actions/cache@v1
+          with:
+            path: ~/.npm
+            key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
+
+        # Also fails — v2 is deprecated
+        - uses: actions/cache@v2
+          with:
+            path: ~/.npm
+            key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
+  - language: yaml
+    label: 'Fix: upgrade to actions/cache v4 (recommended)'
+    code: |
+      steps:
+        - uses: actions/checkout@v4
+
+        # CORRECT: use v4 (or v3 if v3-to-v4 migration is not yet done)
+        - uses: actions/cache@v4
+          with:
+            path: ~/.npm
+            key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
+            restore-keys: |
+              ${{ runner.os }}-npm-
+  - language: yaml
+    label: 'Dependabot config to automatically receive Actions version updates'
+    code: |
+      # .github/dependabot.yml
+      version: 2
+      updates:
+        - package-ecosystem: github-actions
+          directory: /
+          schedule:
+            interval: weekly
+          # Dependabot will open PRs to upgrade actions/cache@v1/v2 → v4 automatically
+prevention:
+  - "Enable Dependabot for GitHub Actions in `.github/dependabot.yml` to receive automated upgrade PRs."
+  - "Search your `.github/workflows/` directory for `actions/cache@v1` and `actions/cache@v2` before the deprecation deadline."
+  - "Check composite actions and reusable workflows — they may internally call deprecated cache versions."
+  - "Audit SHA-pinned action references to ensure the SHA does not point to a v1/v2 release."
+docs:
+  - url: 'https://github.blog/changelog/2024-12-05-notice-of-upcoming-releases-and-breaking-changes-for-github-actions/#actions-cache-v1-v2-and-actions-toolkit-cache-package-closing-down'
+    label: 'GitHub Changelog Dec 2024: actions/cache v1/v2 deprecation notice'
+  - url: 'https://github.com/actions/cache/discussions/1510'
+    label: 'actions/cache Discussion #1510: deprecated version hard failure reports'
+  - url: 'https://github.com/actions/cache'
+    label: 'actions/cache repository — upgrade instructions'
+  - url: 'https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot'
+    label: 'GitHub Docs: Keeping your actions up to date with Dependabot'

package/errors/caching-artifacts/caching-artifacts-057.yml

@@ -0,0 +1,98 @@
+id: caching-artifacts-057
+title: '`actions/cache` Never Refreshes Cached Content — Cache Keys Are Immutable Once Stored'
+category: caching-artifacts
+severity: silent-failure
+tags:
+  - cache
+  - stale
+  - immutable
+  - cache-hit
+  - refresh
+  - node-modules
+patterns:
+  - regex: 'cache-hit.*true.*post.*skip'
+    flags: 'i'
+error_messages:
+  - "Cache hit occurred on the primary key, not saving cache."
+  - "Cache hit occurred on the primary key runner-os-node-"
+root_cause: |
+  `actions/cache` uses immutable cache keys. Once a cache entry is stored for a given
+  key, it cannot be updated or overwritten — any subsequent run that produces an exact
+  key match will restore the cached content and the post step will NOT save a new cache
+  entry because one already exists for that key.
+
+  This means cached content (node_modules, pip packages, Maven artifacts, etc.) is
+  frozen at the point of first creation and will not reflect package updates until:
+  - The cache entry expires (GitHub-hosted caches expire after 7 days of no access)
+  - The cache key changes (e.g., lockfile hash changes)
+  - The cache entry is manually deleted via the GitHub UI or API
+
+  Common misconception: developers expect that running `npm ci` inside a cached
+  node_modules hit will update the cache if packages changed. It won't. The cache key
+  (usually `${{ hashFiles('package-lock.json') }}`) must change for a new cache to be
+  saved.
+
+  Related gotcha: if restore-keys produce a partial hit (different key prefix), the
+  post step DOES save a new cache — but for the full key, not the partial restore key.
+  This creates unexpected cache churn from the developer's perspective where cache hit
+  rate is high but actual content is outdated.
+
+  This is intentional GitHub design but frequently misunderstood, leading to:
+  - Stale node_modules with old transitive dependencies
+  - pip packages that don't receive security patches within 7 days
+  - Build artifacts compiled against old toolchain versions
+fix: |
+  To force periodic cache refresh without changing your lockfile, use one of these patterns:
+
+  1. Include a date-based component in the cache key (weekly rotation).
+  2. Use `actions/cache/restore` + `actions/cache/save` with explicit control of when
+     to save (allows saving even on hits).
+  3. Delete the cache manually via GitHub UI (Actions > Caches) or the API when you
+     need an immediate refresh.
+fix_code:
+  - language: yaml
+    label: "Weekly-rotating cache key to prevent indefinitely stale caches"
+    code: |
+      - name: Get week number for cache rotation
+        id: date
+        run: echo "week=$(date +'%Y-%U')" >> "$GITHUB_OUTPUT"
+
+      - name: Cache node_modules (refreshes weekly)
+        uses: actions/cache@v4
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-node-${{ steps.date.outputs.week }}-${{ hashFiles('**/package-lock.json') }}
+          restore-keys: |
+            ${{ runner.os }}-node-${{ steps.date.outputs.week }}-
+            ${{ runner.os }}-node-
+  - language: yaml
+    label: "Separate restore + save for explicit cache update control"
+    code: |
+      - name: Restore cache
+        id: cache-restore
+        uses: actions/cache/restore@v4
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
+          restore-keys: ${{ runner.os }}-node-
+
+      - run: npm ci
+
+      - name: Save updated cache (always saves, even on hit)
+        uses: actions/cache/save@v4
+        if: always()
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}-${{ github.run_id }}
+prevention:
+  - "Understand that GitHub cache keys are immutable — a key that already exists in the cache will never be overwritten"
+  - "Use time-based or run-id-based cache key suffixes when cached content must be refreshed more frequently than lockfile changes"
+  - "Monitor cache age in the GitHub UI (Actions > Caches) and manually purge entries that appear stale"
+  - "For security-sensitive dependencies, prefer short cache TTLs via run-id keys or disable caching entirely"
+docs:
+  - url: "https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows"
+    label: "GitHub Docs — Caching dependencies to speed up workflows"
+  - url: "https://github.com/actions/cache/blob/main/tips-and-workarounds.md"
+    label: "actions/cache tips and workarounds"
+  - url: "https://github.com/actions/cache/issues/1380"
+    label: "actions/cache #1380 — cache never updates on key hit"

package/errors/known-unsolved/known-unsolved-055.yml

@@ -0,0 +1,124 @@
+id: known-unsolved-055
+title: 'github.event.workflow_run.pull_requests is empty for fork PRs — PR context unavailable in triggered workflow'
+category: known-unsolved
+severity: silent-failure
+tags:
+  - workflow_run
+  - fork
+  - pull-requests
+  - event-context
+  - security
+  - limitation
+  - pull_request
+patterns:
+  - regex: 'github\.event\.workflow_run\.pull_requests'
+    flags: 'i'
+  - regex: 'pull_requests.*\[\]|workflow_run.*pull_requests.*empty'
+    flags: 'i'
+error_messages:
+  - "# No error thrown — github.event.workflow_run.pull_requests evaluates to [] for fork PRs"
+  - "Error: PR number is empty or undefined"
+  - "Cannot read properties of undefined (reading 'number')"
+root_cause: |
+  When a workflow is triggered by on: workflow_run: and the upstream workflow
+  was triggered by a pull_request event from a fork, the
+  github.event.workflow_run.pull_requests array is deliberately empty ([]).
+
+  For same-repository PRs, the pull_requests array is populated with PR
+  metadata (number, head.sha, head.ref, base.ref, etc.). For fork PRs, it
+  is always an empty array for security reasons: GitHub does not expose PR
+  metadata from fork branches through this event payload to prevent
+  untrusted code from accessing repository information via the privileged
+  workflow_run context.
+
+  This is a known, by-design limitation (GitHub closed the tracker issue as
+  "not planned"). The result is that workflows designed to comment on PRs,
+  post status checks, or download artifacts using the PR number silently
+  fail or crash when run against fork-originated pull requests because
+  github.event.workflow_run.pull_requests[0].number evaluates to undefined.
+
+  The limitation is easy to miss during development because the workflow
+  works correctly for PRs from within the same organization — the failure
+  only appears when an external contributor opens a fork PR.
+fix: |
+  Pass the required PR information as an artifact from the upstream
+  (untrusted) workflow to the downstream (privileged) workflow_run workflow.
+  The upstream workflow writes the PR number to a file and uploads it as
+  an artifact; the downstream workflow downloads the artifact and reads
+  the PR number from it.
+
+  This is the officially documented pattern for safe fork PR workflows.
+fix_code:
+  - language: yaml
+    label: 'Upstream (untrusted) workflow — upload PR number as artifact'
+    code: |
+      # .github/workflows/pr-checks.yml (runs on pull_request, limited privileges)
+      name: PR Checks
+      on:
+        pull_request:
+
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: echo "${{ github.event.number }}" > pr_number.txt
+            - uses: actions/upload-artifact@v4
+              with:
+                name: pr-number
+                path: pr_number.txt
+  - language: yaml
+    label: 'Downstream (privileged) workflow — download artifact to get PR number'
+    code: |
+      # .github/workflows/pr-comment.yml (runs on workflow_run, full privileges)
+      name: PR Comment
+      on:
+        workflow_run:
+          workflows: ["PR Checks"]
+          types: [completed]
+
+      jobs:
+        comment:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Download PR number artifact
+              uses: actions/github-script@v7
+              with:
+                script: |
+                  const artifacts = await github.rest.actions.listWorkflowRunArtifacts({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    run_id: context.payload.workflow_run.id,
+                  });
+                  const prArtifact = artifacts.data.artifacts.find(a => a.name === 'pr-number');
+                  if (!prArtifact) { core.setFailed('No pr-number artifact'); return; }
+                  const download = await github.rest.actions.downloadArtifact({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    artifact_id: prArtifact.id,
+                    archive_format: 'zip',
+                  });
+                  require('fs').writeFileSync('pr_number.zip', Buffer.from(download.data));
+            - run: unzip pr_number.zip && echo "PR=$(cat pr_number.txt)" >> $GITHUB_ENV
+            - name: Post comment
+              uses: actions/github-script@v7
+              with:
+                script: |
+                  await github.rest.issues.createComment({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    issue_number: Number(process.env.PR),
+                    body: 'Checks passed!'
+                  });
+prevention:
+  - "Always use the artifact-passing pattern for workflow_run workflows that need PR context — never assume github.event.workflow_run.pull_requests is populated."
+  - "Check the triggering event type: if github.event.workflow_run.event == 'pull_request' and the array is empty, the PR came from a fork."
+  - "Use github.event.workflow_run.head_branch and head_sha for correlating runs, but not for PR numbers (which are unavailable for forks)."
+  - "Consider using the gh-action-pr-number community action which handles the artifact-based lookup pattern automatically."
+docs:
+  - url: 'https://github.com/actions/runner/issues/3444'
+    label: 'actions/runner #3444 — workflow_run from fork pull_request lacks pull_requests payload'
+  - url: 'https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#using-data-from-the-triggering-workflow'
+    label: 'GitHub Docs — Using data from the triggering workflow (artifact pattern)'
+  - url: 'https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run'
+    label: 'GitHub Docs — workflow_run event reference'

package/errors/permissions-auth/permissions-auth-058.yml

@@ -0,0 +1,101 @@
+id: permissions-auth-058
+title: 'actions/checkout does not rewrite ssh:// submodule URLs — only git@github.com: format is rewritten'
+category: permissions-auth
+severity: error
+tags:
+  - checkout
+  - submodules
+  - ssh
+  - gitmodules
+  - URL-rewriting
+  - host-key-verification
+  - ssh-key
+patterns:
+  - regex: 'Host key verification failed'
+    flags: 'i'
+  - regex: 'ssh://.*Permission denied|ssh://.*Could not read from remote'
+    flags: 'i'
+  - regex: 'fatal: clone of .ssh://. into submodule path .* failed'
+    flags: 'i'
+  - regex: 'git@github\.com.*vs.*ssh://github\.com'
+    flags: 'i'
+error_messages:
+  - "Host key verification failed."
+  - "fatal: Could not read from remote repository."
+  - "Please make sure you have the correct access rights and the repository exists."
+  - "fatal: clone of 'ssh://git@github.com/Org/SubRepo.git' into submodule path '<path>' failed"
+root_cause: |
+  actions/checkout rewrites submodule URLs in .gitmodules to inject the
+  provided ssh-key or GITHUB_TOKEN credentials, but the rewriting logic only
+  handles the git@github.com: URL format. URLs using the alternative
+  ssh://git@github.com/ scheme are NOT rewritten and are passed to git
+  as-is.
+
+  When git attempts to clone an ssh:// URL without an SSH agent providing
+  the key, and without the runner having github.com in ~/.ssh/known_hosts,
+  the clone fails with "Host key verification failed." or permission errors.
+
+  The affected code path is actions/checkout/src/git-auth-helper.ts which
+  contains an explicit regex that only matches the git@ style:
+    /^git@github\.com:/
+  The ssh:// variant does not match, so the credential injection and
+  known_hosts population steps are skipped for those URLs.
+
+  This is a confirmed open bug with a pending fix (PR #2367), but as of
+  early 2026 it remains unmerged and unreleased.
+fix: |
+  Convert all submodule URLs in .gitmodules from ssh:// to git@github.com:
+  format. This ensures actions/checkout's URL rewriting logic applies the
+  SSH key and adds the host key to known_hosts.
+
+  If you cannot change .gitmodules (e.g., the submodule is a third-party
+  repo), use a manual git config insteadOf URL rewrite in a pre-checkout
+  step to normalize the URL before the checkout action runs.
+fix_code:
+  - language: bash
+    label: 'Option A — Change .gitmodules to use git@ format instead of ssh://'
+    code: |
+      # .gitmodules — BEFORE (broken)
+      [submodule "MySubrepo"]
+          path = MySubrepo
+          url = ssh://git@github.com/Org/MySubrepo.git
+
+      # .gitmodules — AFTER (working)
+      [submodule "MySubrepo"]
+          path = MySubrepo
+          url = git@github.com:Org/MySubrepo.git
+  - language: yaml
+    label: 'Option B — Add git config URL rewrite step before checkout'
+    code: |
+      steps:
+        - name: Rewrite ssh:// submodule URLs to git@ format
+          run: |
+            git config --global url."git@github.com:".insteadOf "ssh://git@github.com/"
+
+        - uses: actions/checkout@v4
+          with:
+            submodules: recursive
+            ssh-key: ${{ secrets.SSH_DEPLOY_KEY }}
+  - language: yaml
+    label: 'Option C — Use HTTPS with token for submodule auth (avoids SSH entirely)'
+    code: |
+      steps:
+        - uses: actions/checkout@v4
+          with:
+            submodules: recursive
+            token: ${{ secrets.PAT_WITH_SUBMODULE_ACCESS }}
+            # Requires .gitmodules to use https:// URLs
+prevention:
+  - "Standardize on git@github.com: format for all .gitmodules URLs in repositories using actions/checkout with SSH keys."
+  - "Use HTTPS URLs with a PAT for submodule access when possible — this is simpler and avoids SSH host key issues entirely."
+  - "Add a linting step (e.g., grep .gitmodules for ssh://) to your repo's pre-commit hooks to catch the wrong URL format early."
+  - "Track actions/checkout PR #2367 for the fix; upgrade once it is merged and released."
+docs:
+  - url: 'https://github.com/actions/checkout/issues/2178'
+    label: 'actions/checkout #2178 — ssh:// URLs in .gitmodules do not work'
+  - url: 'https://github.com/actions/checkout/pull/2367'
+    label: 'actions/checkout PR #2367 — Fix: also rewrite ssh:// URLs'
+  - url: 'https://github.com/actions/checkout/blob/main/src/git-auth-helper.ts'
+    label: 'actions/checkout git-auth-helper.ts — URL rewriting source code'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-conditions-to-control-job-execution'
+    label: 'GitHub Docs — Checking out submodules'