Skip to content

Install PSScriptAnalyzer directly instead of via psmodulecache - #3034

Closed
nohwnd wants to merge 1 commit into
mainfrom
ci/drop-psmodulecache
Closed

Install PSScriptAnalyzer directly instead of via psmodulecache#3034
nohwnd wants to merge 1 commit into
mainfrom
ci/drop-psmodulecache

Conversation

@nohwnd

@nohwnd nohwnd commented Sep 5, 2026

Copy link
Copy Markdown
Member

Turning on sha_pinning_required broke the PSScriptAnalyzer check, which is a required check, so nothing can merge. This is the fix.

The enforcement is transitive. It applies to actions referenced inside composite actions, not only to the ones in our own workflows. potatoqualitee/psmodulecache is a composite action and its own actions/cache reference is not pinned:

psmodulecache nested reference
v6.2.1 (ours) actions/cache@v4.2.0
v6.3 (latest, what Dependabot #3027 bumps to) actions/cache@v5.0.5

So the job fails at Set up job before running anything, and taking the Dependabot bump does not help, it just moves to a different unpinned reference. We cannot pin someone else's internals.

The step only installed PSScriptAnalyzer and ConvertToSARIF. Installing them straight from PSGallery takes seconds, so the cache was not buying much, and this removes a third-party composite action from the build entirely.

I checked the other six actions we use - checkout, setup-dotnet, upload-artifact, download-artifact, codecov-action, codeql-action - and none of them have unpinned nested references. psmodulecache was the only one, so this is the last blocker to turning sha_pinning_required back on.

🤖

sha_pinning_required applies to actions referenced inside composite actions, not
just to the ones in our own workflows. potatoqualitee/psmodulecache is a composite
action and its own actions/cache reference is not pinned: v6.2.1 uses
actions/cache@v4.2.0 and v6.3 uses @v5.0.5. So the job fails at "Set up job" with

  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.

Taking the Dependabot bump to v6.3 does not help, it just moves to a different
unpinned reference. We cannot pin someone else's internals, so the dependency goes.

The step only installed PSScriptAnalyzer and ConvertToSARIF. Two modules from
PSGallery take seconds, so the cache was not buying much, and dropping it removes
the last blocker to turning sha_pinning_required back on. It was the only action
we use with unpinned nested references, the other six are clean.

🤖
@nohwnd

nohwnd commented Sep 5, 2026

Copy link
Copy Markdown
Member Author

Parking this as a draft. sha_pinning_required is off again so nothing is blocked, and the module cache step predates this work, so I want to discuss it before removing it.

The reason enforcement and psmodulecache cannot coexist is in the description above, and the upstream fix is potatoqualitee/psmodulecache#68.

🤖

@nohwnd

nohwnd commented Sep 5, 2026

Copy link
Copy Markdown
Member Author

Closing in favour of #3036, where the reasoning and the options are written up.

Removing the module cache is only one of four ways to handle this, and it is not obviously the right one until we know what the cache was solving. The policy is off, so nothing is blocked.

🤖

@nohwnd nohwnd closed this Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant