JS-2022 - Fix npm cache never being saved due to lookup-only mode

[nathsou]

Summary

• prepare_rspec_rule_data (and other jobs that only restore the npm cache) fails with sh: 1: tsx: not found whenever a branch's package-lock.json differs from master's — e.g. any PR adding/bumping a root npm dependency. Reproduced on JS-2014: Implement S8980: react testing library calls should not be wrapped in act() #7480, JS-2015: Implement S8981: regular expressions used in Testing Library queries should not have the global flag #7483, JS-2019: Implement S8985: side effects should not be performed inside "waitFor" callbacks #7488 (each adds a new devDependency for a new rule) and on Update dependency tsx to v4.22.5 #7487 (Renovate bump of tsx).
• Root cause (updated — thanks @erwan-leforestier-sonarsource for catching this): populate_npm_cache's "Cache NPM dependencies" step passed lookup-only: true. Since commit 8d5f45db5f ("Skip duplicate S3 cache save when content matches the default-branch fallback"), merged into gh-action_cache's v1 branch on 2026-06-30, that flag makes the action pick mode=lookup — no restore, no save, period. populate_npm_cache was never really saving a branch-scoped cache entry after that; it only appeared to work when a branch's lockfile hash happened to match master's, via the fallback-exact-key path. This is the same latent-bug pattern already fixed for the JS coverage cache in JS-2017 Fix JS coverage handoff for Sonar analysis #7481.
• Fix: pin SonarSource/gh-action_cache to v1.7.1 — that masked a legitimate upstream fix rather than addressing the actual bug on our side, and wouldn't get an upstream fix since there's nothing to fix upstream.
• Actual fix: drop lookup-only: true from populate_npm_cache/populate_npm_cache_win's cache step so it does a normal restore-or-install, letting the action's post-step genuinely save node_modules under the branch's own key. Downstream jobs (build, test_js, test_js_win, prepare_rspec_rule_data) already do a plain restore against that same key and get a real hit once it's actually populated. gh-action_cache stays on @v1.
• Validated directly: merged this fix into JS-2019: Implement S8985: side effects should not be performed inside "waitFor" callbacks #7488 (which has a genuinely different package-lock.json from master). Before the fix, Prepare RSPEC rule data failed there with the exact tsx: not found error; after merging this branch in, Populate NPM cache for Linux/Windows, Prepare RSPEC rule data, and all downstream jobs went green.

Test plan

• CI passes on this PR
• Confirmed on JS-2019: Implement S8985: side effects should not be performed inside "waitFor" callbacks #7488 (differing lockfile) that Prepare RSPEC rule data and downstream jobs go green after this fix
• Rebase JS-2014: Implement S8980: react testing library calls should not be wrapped in act() #7480, JS-2015: Implement S8981: regular expressions used in Testing Library queries should not have the global flag #7483, Update dependency tsx to v4.22.5 #7487 onto this fix once merged and confirm the same

[hashicorp-vault-sonar-prod]

JS-2022

[github-actions]

Ruling Report

Code no longer flagged (2 issues)

S8784

vitest/test/typescript/failing/fail.test-d.ts:15

    13 |   })
    14 | 
>   15 |   expectTypeOf(1).toBeVoid()
    16 | })
    17 | 

vitest/test/typescript/test-d/test.test-d.ts:49

    47 | })
    48 | 
>   49 | expectTypeOf({ wolk: 'true' }).toHaveProperty('wolk')
    50 | 

[vdiez]

we should probably consider using https://github.com/actions/cache directly instead of relying on sonarsource cache action, like we do with the orchestrator cache. I don't think SonarJS benefits/needs S3 caching done by sonarsource cache

[erwan-leforestier-sonarsource]

The issue I fixed yesterday was similar to yours but it was for test coverage files cache, and not for node_modules cache. Here is the link to my PR if you want to have a look: #7481

From what I understood by investigating this issue with codex, this is due to the use of the lookup_only: true flag used in our workflows, that was not properly working before but it's now properly working since the fix in SonarSource/gh-action_cache, the same commit you mentioned: SonarSource/gh-action_cache@8d5f45d

Purpose of this flag is to say "just check that the cache exist but don't read from it and don't save anything in it". Before their fix, it was always reading the cache so we ended up with files available. Now it's breaking because files are not available anymore.

In my other PR, I fixed it by removing this flag which does a normal restore, so it's kind of "Read it from the cache, but if it fails then run tests to generate the test coverage file and populate the cache with it" and I've also added an explicit upload artifacts inside jobs that require these artifacts (in my case, only "Next SonarQube Analysis" needed it).
You probably want the same in your case, "try restore node_modules from the cache but if it fails, run npm i and populate the cache".

All of this to say that downgrading to gh-action_cache is not a good idea because it's not a bug on their side, it's a bug they actually fixed and it will remain like this so there is no upstream fix to expect, this is an issue on our side.

If you're in a hurry, I'm ok downgrading to v1.7 for now but we should at least open a ticket to properly fix our CI later.

[nathsou]

@erwan-leforestier-sonarsource good catch, and thanks for the pointer to #7481 — you were right, this is the same latent-bug pattern.

populate_npm_cache's "Cache NPM dependencies" step was passing lookup-only: true. With the fixed action behavior, that forces mode=lookup (no restore, no save), so the job was never actually saving a branch-scoped node_modules cache entry — it only looked like it worked when a branch's lockfile hash happened to match master's (served via the fallback-exact-key path). Different lockfile hash → no save ever happened → downstream restore-only jobs had nothing to restore.

Dropped lookup-only: true and left it as a normal restore-or-install, same spirit as your coverage-cache fix (just without the artifact-upload step, since the existing downstream jobs already do plain restores against the same key and node_modules is too big to want as a workflow artifact). gh-action_cache stays on @v1, no pin needed.

Validated by merging this fix into #7488 (real lockfile diff there): Prepare RSPEC rule data failed with the original tsx: not found beforehand, and went green afterward along with the rest of the pipeline. Pushed the updated PR description too.

Still agree a tracking ticket for auditing other lookup-only usages in build.yml is worthwhile — will file one, though test_js_win's marker-file check (js-test-win-...) looks like a legitimate lookup-only use since it never needs to restore the marker's content, so I don't think that one needs to change.

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Pins gh-action_cache to v1.7.1 to resolve CI cache misses caused by a downstream regression. Please update the PR title and description to reflect the current implementation state.

💡 Quality: PR title/description no longer matches the actual change

🔗 link

The PR title ("Pin gh-action_cache to v1.7.1") and the summary describe pinning every gh-action_cache usage to v1.7.1. However, the final commit (cc638ba) reverses that approach: all usages remain on the floating @v1 tag and the actual fix is the removal of lookup-only: true from the populate_npm_cache step (net PR diff vs master is only that one deleted line). A reviewer approving based on the current title/summary would expect the opposite of what the code does, and the git history/PR description will be misleading later. Please update the title and summary to reflect the real fix — removing lookup-only: true so the populate job installs and saves node_modules under the branch key instead of relying on the regressed cross-branch fallback restore. Also note the summary's premise that @v1 still contains the regression: confirm downstream jobs are unaffected now that population, rather than the action version, is what changed.

🤖 Prompt for agents

Code Review: Pins `gh-action_cache` to `v1.7.1` to resolve CI cache misses caused by a downstream regression. Please update the PR title and description to reflect the current implementation state.

1. 💡 Quality: PR title/description no longer matches the actual change

   The PR title ("Pin gh-action_cache to v1.7.1") and the summary describe pinning every `gh-action_cache` usage to `v1.7.1`. However, the final commit (`cc638ba`) reverses that approach: all usages remain on the floating `@v1` tag and the actual fix is the removal of `lookup-only: true` from the `populate_npm_cache` step (net PR diff vs master is only that one deleted line). A reviewer approving based on the current title/summary would expect the opposite of what the code does, and the git history/PR description will be misleading later. Please update the title and summary to reflect the real fix — removing `lookup-only: true` so the populate job installs and saves `node_modules` under the branch key instead of relying on the regressed cross-branch fallback restore. Also note the summary's premise that `@v1` still contains the regression: confirm downstream jobs are unaffected now that population, rather than the action version, is what changed.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}