@htekdev/actions-debugger 1.0.123 → 1.0.125

package/errors/runner-environment/runner-environment-224.yml

@@ -0,0 +1,74 @@
+id: runner-environment-224
+title: 'windows-2025-vs2026 UWP builds with PlatformToolset v143 fail with MSB8020'
+category: runner-environment
+severity: error
+tags:
+  - windows
+  - uwp
+  - msvc
+  - vs2026
+  - v143
+  - v145
+  - msbuild
+  - migration
+patterns:
+  - regex: 'MSB8020: The build tools for ''v143'' application Type UWP \(Platform Toolset = ''Visual Studio 2022''\) cannot be found'
+    flags: i
+  - regex: '<PlatformToolset>v143</PlatformToolset>'
+    flags: i
+  - regex: 'windows-2025-vs2026'
+    flags: i
+error_messages:
+  - 'MSBUILD : error MSB8020: The build tools for ''v143'' application Type UWP (Platform Toolset = ''Visual Studio 2022'') cannot be found.'
+  - 'The same project builds cleanly on windows-2025 (VS 2022) because v143 is the native toolset there.'
+root_cause: |
+  The `windows-2025-vs2026` image is a Visual Studio 2026 image. It ships the VS 2026
+  native MSVC toolset (`v145`), but it does NOT include the legacy VS 2022 UWP toolset
+  overlay for `PlatformToolset=v143`.
+
+  Legacy UWP C++ projects often keep `<PlatformToolset>v143</PlatformToolset>` in the
+  `.vcxproj` file. That works on `windows-2025` (VS 2022), but when the same workflow is
+  moved to `windows-2025-vs2026` — or when `windows-latest` rolls onto the VS 2026 image —
+  MSBuild fails at `PrepareForBuild` with MSB8020 before compilation starts.
+
+  Issue #14101 was later clarified by the reporter: the break is real, but the root cause is
+  not a partially missing component. The image is behaving as a VS 2026-only environment, and
+  the workflow is still targeting an older UWP toolset that is no longer present there.
+fix: |
+  Option 1 — Migrate the project to `PlatformToolset=v145` (recommended on VS 2026 images).
+
+  Option 2 — If the project must stay on `v143`, pin the workflow to a VS 2022 image such as
+  `windows-2025` instead of `windows-2025-vs2026` or `windows-latest`.
+
+  Option 3 — Isolate legacy UWP builds in a dedicated workflow that stays on VS 2022 while the
+  rest of the repository migrates to VS 2026.
+fix_code:
+  - language: xml
+    label: 'Migrate the project file to the VS 2026 toolset'
+    code: |
+      <PropertyGroup Label="Configuration">
+        <ConfigurationType>StaticLibrary</ConfigurationType>
+        <PlatformToolset>v145</PlatformToolset>
+      </PropertyGroup>
+
+  - language: yaml
+    label: 'Keep legacy UWP builds on the VS 2022 image'
+    code: |
+      jobs:
+        build-uwp:
+          runs-on: windows-2025
+          steps:
+            - uses: actions/checkout@v4
+            - name: Build legacy UWP project
+              run: msbuild MyApp.sln /p:Configuration=Release /p:Platform=x64
+prevention:
+  - 'Audit Windows workflows for `<PlatformToolset>v143</PlatformToolset>` before moving them to `windows-2025-vs2026` or `windows-latest`.'
+  - 'Treat Visual Studio image migrations as toolchain migrations, not just path changes.'
+  - 'Pin `runs-on` explicitly for legacy UWP projects until the toolset migration is complete.'
+docs:
+  - url: 'https://github.com/actions/runner-images/issues/14101'
+    label: 'actions/runner-images#14101 — windows-2025-vs2026 UWP project fails with MSB8020 on v143'
+  - url: 'https://github.com/actions/runner-images/issues/14017'
+    label: 'actions/runner-images#14017 — Windows 2025 / VS 2026 rollout announcement'
+  - url: 'https://learn.microsoft.com/en-us/cpp/build/reference/msbuild-visual-cpp-overview'
+    label: 'Microsoft Docs — MSBuild and Visual C++ toolsets'

package/errors/runner-environment/runner-environment-225.yml

@@ -0,0 +1,85 @@
+id: runner-environment-225
+title: 'macOS-26 arm runners can miss the iOS 26.1 simulator runtime needed by Xcode 26.1.1'
+category: runner-environment
+severity: error
+tags:
+  - macos
+  - macos-26
+  - arm64
+  - xcode
+  - simulator
+  - ios
+  - xcodebuild
+  - runner-image
+patterns:
+  - regex: 'Unable to find a destination matching the provided destination specifier:'
+    flags: i
+  - regex: 'iOS 26\.1 is not installed\. Please download and install the platform from Xcode > Settings > Components\.'
+    flags: i
+  - regex: 'Exit status: 70'
+    flags: i
+error_messages:
+  - 'xcodebuild: error: Unable to find a destination matching the provided destination specifier:'
+  - '{ platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device, error:iOS 26.1 is not installed. Please download and install the platform from Xcode > Settings > Components. }'
+  - 'Exit status: 70'
+root_cause: |
+  The macOS 26 arm64 image version `20260520.0098.1` can expose Xcode 26.1.1 without shipping
+  the matching iOS 26.1 simulator/runtime components that Apple tooling expects for that Xcode.
+
+  Workflows that switch to Xcode 26.1.1 and build for iOS hit an immediate xcodebuild destination
+  failure because the placeholder device reports `iOS 26.1 is not installed`. The problem is on the
+  runner image, not in the project: the requested platform runtime is simply absent from the hosted
+  image at execution time.
+
+  This differs from the later macOS 26 default-Xcode migration entry: here the failure is a missing
+  runtime on the selected Xcode/image combination, not a project that needs to unpin from an older
+  Xcode.
+fix: |
+  Option 1 — Select an Xcode version whose simulator/runtime set is actually present on the image.
+
+  Option 2 — Use `OS=latest` or another available simulator destination after checking the installed
+  runtimes with `xcrun simctl list runtimes`.
+
+  Option 3 — Wait for the next runner-image rollout that includes the missing iOS 26.1 runtime if the
+  project explicitly requires Xcode 26.1.1.
+fix_code:
+  - language: yaml
+    label: 'Probe runtimes before building and use an installed simulator version'
+    code: |
+      jobs:
+        ios-build:
+          runs-on: macos-26-arm64
+          steps:
+            - uses: actions/checkout@v4
+            - name: Show installed runtimes
+              run: xcrun simctl list runtimes
+            - name: Build with an installed simulator runtime
+              run: |
+                xcodebuild build \
+                  -scheme MyApp \
+                  -destination 'platform=iOS Simulator,OS=latest,name=iPhone 17 Pro'
+
+  - language: yaml
+    label: 'Pin to a different Xcode already supported by the image'
+    code: |
+      jobs:
+        ios-build:
+          runs-on: macos-26-arm64
+          steps:
+            - uses: actions/checkout@v4
+            - uses: maxim-lobanov/setup-xcode@v1
+              with:
+                xcode-version: '26.4.1'
+            - name: Build
+              run: xcodebuild build -scheme MyApp -destination 'generic/platform=iOS'
+prevention:
+  - 'Always dump `xcrun simctl list runtimes` in CI when adopting a new Xcode/image combination.'
+  - 'Prefer `OS=latest` unless your workflow truly requires one exact simulator runtime.'
+  - 'Pin both the runner label and Xcode version during major Apple platform transitions.'
+docs:
+  - url: 'https://github.com/actions/runner-images/issues/14146'
+    label: 'actions/runner-images#14146 — macos-26 arm runner missing iOS simulator 26.1'
+  - url: 'https://developer.apple.com/documentation/xcode/installing-additional-simulator-runtimes'
+    label: 'Apple Docs — Installing additional simulator runtimes'
+  - url: 'https://github.com/maxim-lobanov/setup-xcode'
+    label: 'maxim-lobanov/setup-xcode action'

package/errors/runner-environment/runner-environment-226.yml

@@ -0,0 +1,91 @@
+id: runner-environment-226
+title: '.NET MAUI iOS publish on macOS-26 can fail because Xcode 26.5 lacks the simulator runtime actool expects'
+category: runner-environment
+severity: error
+tags:
+  - macos
+  - macos-26
+  - maui
+  - dotnet
+  - ios
+  - xcode
+  - actool
+  - runner-image
+patterns:
+  - regex: 'No simulator runtime version from \["23B86", "23C54", "23E254a"\] available to use with iphonesimulator SDK version 23F5054d'
+    flags: i
+  - regex: 'xcrun: error: unable to find utility "actool"'
+    flags: i
+  - regex: 'This version of \.NET for iOS \(26\.5\.9001\) requires Xcode 26\.5'
+    flags: i
+error_messages:
+  - 'No simulator runtime version from ["23B86", "23C54", "23E254a"] available to use with iphonesimulator SDK version 23F5054d'
+  - 'xcrun: error: unable to find utility "actool"'
+  - 'This version of .NET for iOS (26.5.9001) requires Xcode 26.5'
+root_cause: |
+  On the early macOS 26 hosted image rollout, users building .NET MAUI iOS apps with
+  `Microsoft.iOS.Sdk` 26.5.9001 were forced into an impossible toolchain combination.
+
+  `Microsoft.iOS.Sdk` 26.5.9001 requires Xcode 26.5, so downgrading to Xcode 26.4.1 is not a valid
+  long-term fix. But the Xcode 26.5 paths that were present on the image had two different failure
+  modes:
+  - selecting `/Applications/Xcode_26.5.app` or `/Applications/Xcode_26.5.0.app` could not resolve
+    `actool`
+  - selecting `/Applications/Xcode_26.5_beta_2.app` resolved `actool`, but the required simulator
+    runtime for SDK `23F5054d` was not installed
+
+  GitHub later confirmed that the Xcode 26.5 runtime would arrive on the next image update. Until
+  that rollout completed, the hosted image simply did not provide a fully working Xcode 26.5 + MAUI
+  iOS 26.5.9001 combination.
+fix: |
+  There is no complete workflow-only fix when the hosted image is missing the runtime that Xcode and
+  the .NET iOS workload require.
+
+  Current options:
+  - wait for the next runner-image rollout that includes the Xcode 26.5 runtime
+  - temporarily downgrade the .NET iOS workload to a version compatible with Xcode 26.4.1
+  - add a preflight check so the job fails fast with a clear message instead of burning minutes in publish
+fix_code:
+  - language: yaml
+    label: 'Fail fast if the required Xcode 26.5 simulator runtime is absent'
+    code: |
+      jobs:
+        publish-ios:
+          runs-on: macos-26
+          steps:
+            - uses: actions/checkout@v4
+            - name: Check installed runtimes
+              run: |
+                xcrun simctl list runtimes
+                xcodebuild -version
+            - name: Guard against missing Xcode 26.5 runtime
+              run: |
+                xcrun simctl list runtimes | grep '23F5054d' || {
+                  echo 'Required Xcode 26.5 simulator runtime is missing on this image.'
+                  exit 1
+                }
+
+  - language: yaml
+    label: 'Pin Xcode 26.4.1 while using a matching older iOS workload'
+    code: |
+      jobs:
+        publish-ios:
+          runs-on: macos-26
+          steps:
+            - uses: actions/checkout@v4
+            - uses: maxim-lobanov/setup-xcode@v1
+              with:
+                xcode-version: '26.4.1'
+            - name: Publish with a workload version that matches Xcode 26.4.1
+              run: dotnet publish -f net9.0-ios -c Release -r ios-arm64
+prevention:
+  - 'Check `xcrun simctl list runtimes` whenever you adopt a new Xcode or .NET iOS workload on hosted macOS images.'
+  - 'Pin both Xcode and the .NET iOS workload version together during Apple platform transitions.'
+  - 'Add a fast runtime preflight before long `dotnet publish` steps so broken image rollouts fail immediately.'
+docs:
+  - url: 'https://github.com/actions/runner-images/issues/14128'
+    label: 'actions/runner-images#14128 — macOS-26 hosted image missing simulator runtime required by Xcode 26.5'
+  - url: 'https://github.com/actions/runner-images/pull/14114'
+    label: 'runner-images pull request referenced in the fix confirmation'
+  - url: 'https://learn.microsoft.com/en-us/dotnet/maui/ios/deployment/'
+    label: 'Microsoft Docs — .NET MAUI iOS deployment'

package/errors/runner-environment/runner-environment-227.yml

@@ -0,0 +1,106 @@
+id: runner-environment-227
+title: 'Bash script handler unquoted path breaks job hooks and run steps in directories with spaces'
+category: runner-environment
+severity: error
+tags:
+  - bash
+  - hooks
+  - spaces
+  - path
+  - job-hooks
+  - self-hosted
+  - script-handler
+patterns:
+  - regex: 'bash: .+: No such file or directory'
+    flags: 'i'
+  - regex: 'ACTIONS_RUNNER_HOOK_JOB_STARTED.+No such file'
+    flags: 'i'
+  - regex: 'bash.*--noprofile.*--norc.*-e.*-o pipefail'
+    flags: 'i'
+error_messages:
+  - 'bash: /Volumes/My: No such file or directory'
+  - 'bash: Shared Files/hook.sh: No such file or directory'
+  - 'Error: Process completed with exit code 127.'
+root_cause: |
+  In the GitHub Actions runner source code, the default argument template for the bash
+  shell handler (`ScriptHandlerHelpers.cs`) does not quote the script path placeholder:
+
+    _defaultArguments["bash"] = "--noprofile --norc -e -o pipefail {0}";
+
+  When `{0}` is replaced with a path containing spaces — such as
+  `/Volumes/My Shared Files/hook.sh` — the resulting command becomes:
+
+    bash --noprofile --norc -e -o pipefail /Volumes/My Shared Files/hook.sh
+
+  Bash treats this as three separate arguments: `/Volumes/My`, `Shared`, and
+  `Files/hook.sh`. The first token is not a valid path, so bash exits with
+  "No such file or directory" and exit code 127.
+
+  By contrast, the PowerShell and cmd templates DO quote the path:
+    _defaultArguments["pwsh"]       = "-command \"& '{0}'\"";
+    _defaultArguments["powershell"] = "-command \". '{0}'\"";
+    _defaultArguments["cmd"]        = "/D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"";
+
+  Only bash and sh are affected. The affected scenarios include:
+  - Job hooks (ACTIONS_RUNNER_HOOK_JOB_STARTED, ACTIONS_RUNNER_HOOK_JOB_COMPLETED)
+    when the hook script resides in a directory whose path contains spaces — a common
+    case on macOS with Tart VMs that mount shared directories at
+    `/Volumes/My Shared Files/`.
+  - `run:` steps where the runner's _work directory path contains spaces (less common
+    but possible on custom self-hosted runner installations).
+
+  The bug affects all released runner versions (no version introduced it — the
+  template has always been unquoted). A fix was proposed in the issue but had not
+  shipped as of the issue filing date.
+fix: |
+  Workaround: avoid spaces in the path to hook scripts and runner working directories.
+
+  1. Move hook scripts to a path with no spaces (e.g., `/opt/runner-hooks/hook.sh`
+     instead of `/Volumes/My Shared Files/hooks/hook.sh`).
+     Set ACTIONS_RUNNER_HOOK_JOB_STARTED=/opt/runner-hooks/job-started.sh in the
+     runner environment (`.env` file or system environment).
+
+  2. On macOS with Tart VMs, use a symlink from a space-free path to the shared
+     volume's hook script:
+       ln -s "/Volumes/My Shared Files/hook.sh" /opt/hooks/job-started.sh
+     Set the env var to the symlink path.
+
+  3. Wrap the script invocation in a no-space wrapper script that calls the real path.
+
+  There is no supported way to override the bash argument template at the user level.
+  The permanent fix requires a runner source code change (quoting `{0}`).
+fix_code:
+  - language: bash
+    label: 'Create a space-free symlink to the actual hook script'
+    code: |
+      # On macOS: create a symlink from a no-space path to the hook in the shared volume
+      mkdir -p /opt/runner-hooks
+      ln -sf "/Volumes/My Shared Files/hooks/job-started.sh" /opt/runner-hooks/job-started.sh
+      ln -sf "/Volumes/My Shared Files/hooks/job-completed.sh" /opt/runner-hooks/job-completed.sh
+
+      # In the runner's .env file (located in the runner install directory):
+      # ACTIONS_RUNNER_HOOK_JOB_STARTED=/opt/runner-hooks/job-started.sh
+      # ACTIONS_RUNNER_HOOK_JOB_COMPLETED=/opt/runner-hooks/job-completed.sh
+
+  - language: bash
+    label: 'Move hook scripts to a space-free directory at runner setup time'
+    code: |
+      # Preferred: install hook scripts in a path with no spaces from the start
+      sudo mkdir -p /usr/local/runner-hooks
+      sudo cp ./hooks/job-started.sh /usr/local/runner-hooks/
+      sudo chmod +x /usr/local/runner-hooks/job-started.sh
+
+      # In .env:
+      # ACTIONS_RUNNER_HOOK_JOB_STARTED=/usr/local/runner-hooks/job-started.sh
+prevention:
+  - 'Always install runner hook scripts under paths with no spaces — use /opt/, /usr/local/, or /home/<user>/ prefixes.'
+  - 'On macOS Tart VM hosts, avoid mounting shared directories with spaces in the volume name; use snake_case or hyphenated names (e.g., My_Shared_Files).'
+  - 'After configuring ACTIONS_RUNNER_HOOK_JOB_STARTED, test the hook manually by running bash --noprofile --norc -e -o pipefail <path> to catch path issues before the runner is live.'
+  - 'If the runner work directory path contains spaces, reconfigure the runner with a clean no-space _work path.'
+docs:
+  - url: 'https://github.com/actions/runner/issues/4404'
+    label: 'actions/runner#4404 — Bash script handler does not quote the script path'
+  - url: 'https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job'
+    label: 'GitHub Docs — Running scripts before or after a job (job hooks)'
+  - url: 'https://github.com/actions/runner/blob/main/src/Runner.Worker/Handlers/ScriptHandlerHelpers.cs'
+    label: 'actions/runner source — ScriptHandlerHelpers.cs (unquoted bash template)'

package/errors/runner-environment/runner-environment-228.yml

@@ -0,0 +1,117 @@
+id: runner-environment-228
+title: 'setup-node@v6 cache detection fails when .yarnrc.yml contains approvedGitRepositories (yarn 4.14+)'
+category: runner-environment
+severity: error
+tags:
+  - setup-node
+  - yarn
+  - cache
+  - yarnrc
+  - approvedGitRepositories
+  - yarn-4
+  - cache-detection
+patterns:
+  - regex: 'Unrecognized or legacy configuration settings found: approvedGitRepositories'
+    flags: 'i'
+  - regex: "The 'yarn config get cacheFolder' command failed with exit code"
+    flags: 'i'
+  - regex: 'yarn config get cacheFolder.*exit code: 1'
+    flags: 'i'
+error_messages:
+  - "Usage Error: Unrecognized or legacy configuration settings found: approvedGitRepositories - run \"yarn config -v\" to see the list of settings supported in Yarn"
+  - "Error: The 'yarn config get cacheFolder' command failed with exit code: 1"
+root_cause: |
+  Yarn 4.14 introduced the `approvedGitRepositories` security setting in `.yarnrc.yml`.
+  This key enforces an allowlist of Git repository URLs that yarn is permitted to fetch
+  packages from, blocking unapproved source URLs with:
+
+    "Request to '<url>' has been blocked because it doesn't match any of the
+    patterns in 'approvedGitRepositories'"
+
+  However, any `.yarnrc.yml` key that is unrecognized or deprecated by the currently
+  installed version of yarn causes yarn to abort ALL config commands with:
+
+    "Usage Error: Unrecognized or legacy configuration settings found: approvedGitRepositories"
+
+  The `actions/setup-node@v6` action detects the yarn cache folder path by executing
+  `yarn config get cacheFolder` early in the action — before any Node.js version is
+  installed and before yarn itself is updated. If the runner's bundled yarn version is
+  older than 4.14, it does not recognize `approvedGitRepositories` and aborts.
+
+  The action catches the non-zero exit code and surfaces the error:
+    "Error: The 'yarn config get cacheFolder' command failed with exit code: 1"
+
+  This failure prevents setup-node from resolving the yarn cache path, breaking the
+  entire step. Users frequently observe this when:
+  - Upgrading to yarn 4.14+ and adding `approvedGitRepositories` to `.yarnrc.yml`
+  - Running on hosted runners where the system yarn version is older than 4.14
+  - Running on self-hosted runners with a frozen yarn version
+
+  The root issue is that yarn's unrecognized-key validation is global — it aborts even
+  read-only config queries when any single key is unrecognized, even if that key is not
+  related to the query.
+fix: |
+  Option 1 — Remove cache:yarn from setup-node (safest immediate fix).
+  Set cache: '' or omit the cache: input entirely. Manage yarn caching with a separate
+  actions/cache step pointed directly at the yarn cache directory.
+
+  Option 2 — Pin the yarn version in the runner environment to match .yarnrc.yml.
+  Ensure the yarn version on the runner is >= 4.14.0 so it recognizes
+  approvedGitRepositories before setup-node calls yarn config get.
+
+  Option 3 — Upgrade setup-node to a version that handles this gracefully.
+  Track actions/setup-node#1534 for a fix that makes cache folder detection resilient
+  to yarn config validation errors.
+
+  Option 4 — Use a separate cache step instead of setup-node's built-in cache.
+  This avoids the setup-node yarn version probe entirely.
+fix_code:
+  - language: yaml
+    label: 'Remove cache:yarn from setup-node and use a standalone cache step'
+    code: |
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          # Do NOT set cache: yarn — it triggers yarn config get cacheFolder
+          # which fails when approvedGitRepositories is in .yarnrc.yml
+
+      # Manage yarn cache manually
+      - name: Get yarn cache directory
+        id: yarn-cache-dir
+        run: echo "dir=$(yarn config get cacheFolder)" >> $GITHUB_OUTPUT
+
+      - uses: actions/cache@v4
+        with:
+          path: ${{ steps.yarn-cache-dir.outputs.dir }}
+          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
+          restore-keys: |
+            ${{ runner.os }}-yarn-
+
+      - run: yarn install --immutable
+
+  - language: yaml
+    label: 'Pin yarn version to 4.14+ before setup-node runs'
+    code: |
+      - name: Enable corepack with matching yarn version
+        run: |
+          corepack enable
+          corepack prepare yarn@4.14.1 --activate
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: yarn   # Now safe — yarn 4.14+ recognizes approvedGitRepositories
+prevention:
+  - 'After adding any new key to .yarnrc.yml, verify it is recognized by running yarn config -v locally and confirming the key appears in the supported list.'
+  - 'When using setup-node cache:yarn with yarn 4+, pin the yarn version via packageManager in package.json or via corepack before the setup-node step.'
+  - 'Monitor actions/setup-node release notes for fixes to yarn cache detection resilience (issue #1534).'
+  - 'If .yarnrc.yml uses security features added in a recent yarn release, document the minimum required yarn version in your repo README and CI setup guide.'
+docs:
+  - url: 'https://github.com/actions/setup-node/issues/1534'
+    label: 'actions/setup-node#1534 — Problem with yarn v4.14 config approvedGitRepositories'
+  - url: 'https://github.com/yarnpkg/berry/issues/7108'
+    label: 'yarnpkg/berry#7108 — approvedGitRepositories config key tracking issue'
+  - url: 'https://yarnpkg.com/configuration/yarnrc#approvedGitRepositories'
+    label: 'Yarn docs — approvedGitRepositories configuration'
+  - url: 'https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#caching-packages-data'
+    label: 'setup-node — Advanced usage: caching packages data'

package/errors/runner-environment/runner-environment-229.yml

@@ -0,0 +1,119 @@
+id: runner-environment-229
+title: 'runner-container-hooks v0.8.0+ breaks local composite actions and event.json in Kubernetes job containers'
+category: runner-environment
+severity: error
+tags:
+  - runner-container-hooks
+  - kubernetes
+  - ARC
+  - local-actions
+  - composite-action
+  - job-container
+  - GITHUB_EVENT_PATH
+patterns:
+  - regex: "Can't find 'action\\.yml', 'action\\.yaml' or 'Dockerfile' under '.+\\.github/actions/.+'"
+    flags: 'i'
+  - regex: 'GITHUB_EVENT_PATH .+/github/workflow/event\\.json does not exist'
+    flags: 'i'
+  - regex: 'Did you forget to run actions/checkout before running your local action'
+    flags: 'i'
+error_messages:
+  - "Error: Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/_work/<repo>/<repo>/.github/actions/<action-name>'. Did you forget to run actions/checkout before running your local action?"
+  - "GITHUB_EVENT_PATH /github/workflow/event.json does not exist"
+root_cause: |
+  In `runner-container-hooks` v0.8.0 (released with actions-runner v2.334.0),
+  PR #244 replaced the shared PersistentVolumeClaim (PVC) between the runner
+  pod and job pods with exec-based file copying.
+
+  Two distinct regressions were introduced:
+
+  **1. Local composite actions fail ("Can't find action.yml")**
+  In `runScriptStep`, only the `_temp` directory is synced back from the job
+  pod to the runner host after each step. When `actions/checkout` runs inside
+  the job pod, the entire repository (including `.github/actions/`) is written
+  to `/__w/<owner>/<repo>/` inside the pod — but it is never copied back to
+  the runner host filesystem.
+
+  The runner resolves local actions by reading `action.yml` from its own
+  filesystem before dispatching the hook for that step. Since the workspace
+  was never synced back, the runner cannot find the action definition and
+  fails with the "Did you forget to run actions/checkout?" error — even
+  though checkout ran successfully inside the pod.
+
+  `runContainerStep` is not affected: it copies the full `/__w` back from
+  the job pod because container action steps run in a separate pod.
+
+  **2. GITHUB_EVENT_PATH missing for jobs without custom volume mounts**
+  In v0.7.0, `/github/home` and `/github/workflow` were set up as volume
+  subPath mounts on every job container. PR #244 replaced these mounts with
+  a `prepareJobScript` call that copies these directories into place — but
+  only when `args.container.userMountVolumes` is non-empty. If the workflow
+  has no custom `volumes:` in the `container:` block, the script never runs
+  and `/github/workflow/event.json` is never created.
+
+  Any action that reads `GITHUB_EVENT_PATH` (e.g. `dorny/paths-filter`,
+  `tj-actions/changed-files`, `actions/github-script` reading the event
+  payload) then fails because the file does not exist.
+
+  Both regressions affect Kubernetes-based ARC (Actions Runner Controller)
+  setups using runner-container-hooks v0.8.0+. Standard GitHub-hosted runners
+  and self-hosted runners that do NOT use container-hooks are unaffected.
+fix: |
+  **Immediate workaround:**
+  Pin `runner-container-hooks` to v0.7.0 by setting the container hooks
+  image in your ARC `HorizontalRunnerAutoscaler` or `RunnerDeployment`
+  configuration to use the v0.7.0 bundle (included in
+  `ghcr.io/actions/actions-runner:2.333.0`).
+
+  **For the local action failure specifically:**
+  After a fix is available upstream, the recommended approach is to upgrade
+  to a patched version of `runner-container-hooks` that copies `.github/`
+  back from the job pod after each `runScriptStep`.
+
+  **For the GITHUB_EVENT_PATH issue specifically:**
+  Ensure your `container:` block includes at least one `volumes:` entry to
+  trigger `prepareJobScript`, or wait for the upstream fix that unconditionally
+  runs the prepare script.
+
+  Track the upstream fix in actions/runner-container-hooks#337.
+fix_code:
+  - language: yaml
+    label: 'Pin ARC runner to actions-runner v2.333.0 (uses hooks v0.7.0) to avoid regression'
+    code: |
+      # In your HorizontalRunnerAutoscaler spec, pin the runner image
+      # to the last version that uses runner-container-hooks v0.7.0:
+      spec:
+        template:
+          spec:
+            image: ghcr.io/actions/actions-runner:2.333.0
+  - language: yaml
+    label: 'Workaround for GITHUB_EVENT_PATH: add a dummy volume mount to trigger prepareJobScript'
+    code: |
+      jobs:
+        build:
+          runs-on: self-hosted
+          container:
+            image: my-ci-image:latest
+            # Adding any volume entry triggers prepareJobScript and restores
+            # /github/workflow/event.json inside the job container
+            volumes:
+              - /tmp:/tmp
+          steps:
+            - uses: actions/checkout@v4
+            - uses: dorny/paths-filter@v3
+              with:
+                filters: |
+                  src:
+                    - 'src/**'
+prevention:
+  - 'When upgrading ARC runner images, check the bundled runner-container-hooks version and validate that local composite actions still work after the upgrade.'
+  - 'Pin runner images to a specific version tag rather than `latest` so unexpected upgrades do not break your workflows.'
+  - 'After upgrading runner-container-hooks, run a canary workflow that (a) uses a local composite action and (b) uses an action that reads GITHUB_EVENT_PATH to catch both regressions early.'
+  - 'Monitor the actions/runner-container-hooks releases page and the linked issue #337 for the official fix.'
+docs:
+  - url: 'https://github.com/actions/runner-container-hooks/issues/337'
+    label: 'actions/runner-container-hooks#337 — Local actions fail after PR #244 removed shared volume'
+  - url: 'https://github.com/actions/runner-container-hooks/pull/244'
+    label: 'actions/runner-container-hooks#244 — Remove dependency on the runner''s volume (introduced regression)'
+  - url: 'https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller'
+    label: 'GitHub Docs — About Actions Runner Controller'