🏁 Script executed:

cat .github/workflows/il2cpp-build-check.yml | head -100

Repository: ifBars/S1API

Length of output: 4632

🌐 Web query:

GitHub Actions cache actions/cache/save immutability can overwrite existing key v4

💡 Result:

No—with actions/cache/save@v4 you cannot overwrite an existing cache entry for the same key. GitHub Actions caches are immutable: if a cache with that key already exists, the save step will not create a new cache (so the existing cache remains unchanged). You must use a new key to save updated contents. [1], [2]

Common workaround (“update” behavior): save with a unique key per run (e.g., include github.run_id or a timestamp) and use restore-keys to restore the closest prior cache. This creates new cache entries and can increase cache/quota usage. [3]

🌐 Web query:

GitHub Actions cache key strategy best practices including external repository revision

💡 Result:

Cache key best practices (GitHub Actions)

• Key should change when inputs that affect the cache change: typically include OS + toolchain/runtime version + dependency lockfile hash (e.g., hashFiles('**/package-lock.json')). GitHub explicitly recommends hashFiles to create new caches when dependencies change. [1]
• Use restore-keys for “closest match” fallbacks (ordered most-specific → least-specific) to improve hit rate while still allowing a full re-save on a miss. GitHub documents the prefix-match behavior for key and restore-keys. [2]
• Avoid over-busting: don’t include highly volatile values (timestamps, run IDs) unless you intentionally want a near-zero hit rate.
• Remember cache compatibility constraints: caches are also stamped by a cache version (derived from paths + compression tool), so cross-OS restores may not work as you expect. [1][2]
• Stay within limits/eviction realities (10GB default repo limit; caches not accessed for 7 days are removed), and design keys to reduce “cache thrash.” [1][2]

Including an external repository revision in the cache key

Because cache keys can include arbitrary command output, you can embed the external repo’s exact commit SHA in the key. [1]

Pattern A — external repo checked out into a subdirectory

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Checkout external repo
        uses: actions/checkout@v4
        with:
          repository: org/external-repo
          path: _external
          fetch-depth: 1

      - name: Get external repo revision
        id: extrev
        run: echo "sha=$(git -C _external rev-parse HEAD)" >> "$GITHUB_OUTPUT"

      - uses: actions/cache@v4
        with:
          path: |
            ~/.npm
            node_modules
          key: >
            npm-${{ runner.os }}-node20-
            ext-${{ steps.extrev.outputs.sha }}-
            lock-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            npm-${{ runner.os }}-node20-ext-${{ steps.extrev.outputs.sha }}-
            npm-${{ runner.os }}-node20-

Why this works: when the external repo updates (different SHA), you naturally get a new cache namespace; when it doesn’t, you keep reusing the same cache. Using a fallback restore-keys keeps performance decent if only the lockfile changes. [1][2]

Pattern B — submodules

If you use git submodules, capture the pinned submodule commit(s) (e.g., git submodule status --recursive) and hash it into the key (same idea: derive a deterministic “external revision fingerprint,” then include it).

Source notes: GitHub’s cache docs show (1) using hashFiles for dependency-sensitive keys and (2) using command outputs as part of keys; they also document restore-keys prefix matching and general cache behavior/limits. [1][2]

Sources:
[1] actions/cache documentation (creating keys; command output in keys; cache version notes) (github.com)
[2] GitHub Docs — “Caching dependencies to speed up workflows” (key matching; restore-keys; limits/eviction) (docs.github.com)

Citations:

• 1: https://github.com/actions/cache?utm_source=openai
• 2: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows?utm_source=openai

🏁 Script executed:

sed -n '395,410p' .github/workflows/il2cpp-build-check.yml

Repository: ifBars/S1API

Length of output: 991

🏁 Script executed:

# Also check if there's any cache save step in the file
rg -n "cache/save" .github/workflows/il2cpp-build-check.yml -A 8

Repository: ifBars/S1API

Length of output: 683

‼️ 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.

🌐 Web query:

GitHub Actions fork pull request cache write permissions actions/cache/save

💡 Result:

• In workflows triggered by pull_request from a fork, GitHub forces GITHUB_TOKEN to be read-only, even if you set permissions: actions: write (public forks are a special case). That means actions/cache/save can’t write/update caches in the base repo in that context. [1]
• For private/internal repos, you can opt into allowing fork PRs to receive a write token via Settings → Actions → General → “Fork pull request workflows” → “Send write tokens to workflows from pull requests”; otherwise fork PRs run read-only with no secrets. [2]
• If you switch to pull_request_target to get a write-capable token, GitHub explicitly warns this runs in the base repo security context (write token + secrets) and caches share base-branch scope—so you should not save caches if untrusted PR code could have modified them (cache poisoning risk). [3]
• Practical patterns:
  • Don’t call actions/cache/save on fork PRs; only restore (or just rely on actions/cache’s normal behavior where save won’t be possible). [4]
  • Save/update caches on trusted events like push to default branch, or a separate post-merge workflow.
  • If using pull_request_target, avoid checking out/running untrusted PR code in the same job that can write caches. [3]

Sources:
[1] https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/ (github.blog)
[2] https://docs.github.com/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository (docs.github.com)
[3] https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/ (securitylab.github.com)
[4] https://github.com/marketplace/actions/cache (github.com)

Citations:

• 1: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/?utm_source=openai
• 2: https://docs.github.com/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository?utm_source=openai
• 3: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/?utm_source=openai
• 4: https://github.com/marketplace/actions/cache

🌐 Web query:

GitHub Actions actions/cache/save behavior existing key duplicate

💡 Result:

actions/cache/save (and actions/cache) will not overwrite an existing cache entry for the same (key + version + branch scope). If the key already exists, no new cache is created (caches are effectively immutable); instead you must save under a new key. [1][2]

If two jobs/runs try to save the same key around the same time (or one already saved it), the save can fail with an error like “Unable to reserve cache… Cache already exists.” [3]

Practical implications / fixes

• To avoid duplicates: run restore first and only save when cache-hit != 'true'. [1]
• To “update” a cache: change the key (e.g., include hashFiles(...), a build id, date, etc.), because you can’t modify an existing cache. [2]

Sources:
[1] actions/cache README (GitHub) (github.com)
[2] GitHub Docs: caching dependencies / immutability (“You cannot change the contents of an existing cache…”) (docs.github.com)
[3] actions/toolkit issue showing “Unable to reserve cache… Cache already exists.” (github.com)

Citations:

• 1: https://github.com/actions/cache?utm_source=openai
• 2: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows?utm_source=openai
• 3: @actions/cache not restoring cache, version mismatch? actions/toolkit#1377

🏁 Script executed:

find . -name "il2cpp-build-check.yml" -type f

Repository: ifBars/S1API

Length of output: 98

🏁 Script executed:

cat -n .github/workflows/il2cpp-build-check.yml | head -450 | tail -100

Repository: ifBars/S1API

Length of output: 5820

🏁 Script executed:

cat -n .github/workflows/il2cpp-build-check.yml | head -250 | tail -150

Repository: ifBars/S1API

Length of output: 8269

🏁 Script executed:

cat -n .github/workflows/il2cpp-build-check.yml | grep -A 5 -B 5 "cache/restore\|Restore IL2CPP"

Repository: ifBars/S1API

Length of output: 903

🏁 Script executed:

cat -n .github/workflows/il2cpp-build-check.yml | grep -A 20 "Fetch Game Version\|il2cpp-scheduleone-assemblies" | head -60

Repository: ifBars/S1API

Length of output: 3980

🏁 Script executed:

cat -n .github/workflows/il2cpp-build-check.yml | head -70 | tail -30

Repository: ifBars/S1API

Length of output: 1814

🌐 Web query:

GitHub Actions undefined step outputs empty string conditional comparison

💡 Result:

In GitHub Actions expressions, a step output is always treated as a string (steps.<id>.outputs.<name>), and if that output was never set, it effectively behaves like an empty string ('') in later expressions/conditionals. (docs.github.com)

Practical ways to handle “undefined output”

Check for non-empty (recommended):

- if: ${{ steps.build.outputs.image_tag != '' }}
  run: echo "tag is set"

Falsy values in if: include "" and null, so this also works:

- if: ${{ steps.build.outputs.image_tag }}
  run: echo "tag is set"

(docs.github.com)

Provide a default (sentinel) value:

env:
  IMAGE_TAG: ${{ steps.build.outputs.image_tag || 'UNSET' }}

Then test env.IMAGE_TAG == 'UNSET'. (This pattern is commonly used because empty/undefined frequently collapse to "".) (docs.github.com)

Common gotcha: comparing to booleans

Even if you “set” true/false, outputs arrive as strings, so compare to 'true' / 'false':

- if: ${{ steps.prev.outputs.ok == 'true' }}
  run: echo "ok"

(docs.github.com)

Citations:

• 1: https://docs.github.com/actions/reference/workflows-and-actions/expressions?utm_source=openai
• 2: https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/expressions?utm_source=openai
• 3: https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/expressions?utm_source=openai
• 4: https://docs.github.com/actions/reference/workflows-and-actions/expressions?utm_source=openai

🏁 Script executed:

cat -n .github/workflows/il2cpp-build-check.yml | sed -n '1,50p'

Repository: ifBars/S1API

Length of output: 2067