Module cache in code-analysis blocks SHA pinning enforcement

[nohwnd]

GitHub's "Require actions to be pinned to a full-length commit SHA" (Settings > Actions > General) applies to actions referenced inside composite actions, not only to the ones in our own workflows. potatoqualitee/psmodulecache is a composite action and does not pin its own actions/cache reference:

psmodulecache	nested reference
v6.2.1 (what we use)	actions/cache@v4.2.0
v6.3 (latest)	actions/cache@v5.0.5

With the policy on, code-analysis.yml fails at Set up job before running anything:

Error: The action actions/cache@v4.2.0 is not allowed in pester/Pester because all
actions must be pinned to a full-length commit SHA.

PSScriptAnalyzer is a required check, so that blocks every merge. The policy is off again, so nothing is broken right now.

Bumping to v6.3 does not help, it just moves to a different unpinned reference. I sent potatoqualitee/psmodulecache#68 upstream to pin it, but even if that merges we stay coupled to their internal pinning from one release to the next.

psmodulecache is the only action we use with unpinned nested references. checkout, setup-dotnet, upload-artifact, download-artifact, codecov-action and codeql-action are all clean, and main, rel/4.x.x, rel/5.x.x and rel/6.0.x are fully pinned.

Timing, for what it is worth

• CI, the 8-leg matrix: 638-743 s
• Code analysis: 65-92 s
• Installing PSScriptAnalyzer and ConvertToSARIF straight from PSGallery: 21 s, measured

The two workflows run in parallel, so code analysis finishes well before CI either way.

Options

1. Keep psmodulecache and leave the policy off. Nothing to do.
2. Keep psmodulecache, turn the policy on once upstream pins and we bump. Breaks again if a later release un-pins.
3. Cache with actions/cache pinned directly in our own workflow. Keeps the caching, drops the composite action, roughly six lines.
4. Install the two modules directly, no cache.

@fflaten

You added the module cache and I do not want to remove something without understanding what it was for. Was it build time, or was it PSGallery being slow or rate limited? If it is about reliability rather than speed then options 3 and 4 are not equivalent, and I would rather keep the cache and solve the pinning differently.

🤖

[fflaten]

Not critical, just optimizing speed and reliability for external dependency as it runs often.

Can easily be skipped, or replaced by actions/cache with a proper cache key if you want.

I'm also sure they'll merge the upstream PR, no reason not to.

[nohwnd]

Small correction to the table above: #3027 merged, so we are on psmodulecache v6.3 now, not v6.2.1. The conclusion is unchanged, v6.3 references actions/cache@v5.0.5 and that is still not pinned.

Also worth noting since the workflows moved: code-analysis.yml is folded into ci.yml as the pssa job, so the step in question is there now rather than in its own file.

🤖