Post-step caches: TrustedSigning PowerShell module cache fails silently with non-zero exit on github-hosted Windows runners

[asaffulks]

Summary

When azure/trusted-signing-action@v1.2.0 runs successfully on a windows-2022 github-hosted runner, the post-step cache cleanup exits non-zero after the publish flow has already completed successfully. Specifically, the 4th internal actions/cache@v5.0.4 invocation — for the TrustedSigning PowerShell module at $PSMODULEPATH\TrustedSigning\0.5.8 — invokes tar.exe to archive the cache, then silently terminates without emitting any further output (no Sent: …/…, no Cache saved with key:, no error message). The step transitions to the next post-step ~0.4 seconds later, marked failed.

Net effect: workflow runs that produce verified-signed releases still show ❌ on the Actions tab, which is noisy for downstream consumers (PR check status, release-monitoring tooling).

Repro

windows-2022 github-hosted runner. Action used to sign a small (~74 KB) native Windows EXE and a larger (~510 MB) NSIS installer. Cert profile validated; auth via direct service-principal client secret. Action invocation:

- name: Sign installer
  uses: azure/trusted-signing-action@v1.2.0
  with:
    azure-tenant-id:          ${{ secrets.AZURE_TENANT_ID }}
    azure-client-id:          ${{ secrets.AZURE_CLIENT_ID }}
    azure-client-secret:      ${{ secrets.AZURE_CLIENT_SECRET }}
    endpoint:                 https://wus2.codesigning.azure.net
    signing-account-name:     <redacted>
    certificate-profile-name: <redacted>
    files:                    <absolute path to .exe>
    file-digest:              SHA256
    timestamp-rfc3161:        http://timestamp.acs.microsoft.com/

The signing call succeeds (Status: Valid via Get-AuthenticodeSignature on the downloaded asset). Post-step then fails.

Post-step log (key excerpts)

Post-steps run in reverse pre-order, so the visible cleanup sequence is:

[warning]Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.
Post job cleanup.
[command]"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tzst --exclude cache.tzst -P -C D:/a/<repo> --files-from manifest.txt --force-local --use-compress-program "zstd -T0"
Sent 27842780 of 27842780 (100.0%), 20.4 MBs/sec
Cache saved with key: Microsoft.Trusted.Signing.Client-1.0.95
Post job cleanup.
[command]"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tzst --exclude cache.tzst -P -C D:/a/<repo> --files-from manifest.txt --force-local --use-compress-program "zstd -T0"
Sent 43521240 of 43521240 (100.0%), 23.1 MBs/sec
Cache saved with key: Microsoft.Windows.SDK.BuildTools-10.0.26100.4188
Post job cleanup.
[command]"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tzst --exclude cache.tzst -P -C D:/a/<repo> --files-from manifest.txt --force-local --use-compress-program "zstd -T0"
<step ends here — no further output, marked failed>

• Post-cache 1 (SignCli, ~\AppData\Local\TrustedSigning\sign\sign...): path doesn't exist (SignCli wasn't installed because our files are .exe, routed to SignTool). Save correctly skipped with the warning.
• Post-cache 2 (Microsoft.Trusted.Signing.Client-1.0.95): saved ✓
• Post-cache 3 (Microsoft.Windows.SDK.BuildTools-10.0.26100.4188): saved ✓
• Post-cache 4 (TrustedSigning-0.5.8 PowerShell module at $PSMODULEPATH\TrustedSigning\0.5.8): tar invoked, no further output, step terminates non-zero.

Hypothesis

The PowerShell module cache step's path: resolves against $PSMODULEPATH, which is multi-valued on Windows runners (system module path + user module path, separated by ;). The cache step may be passing one valid path + one invalid path to tar, or the resolved path is itself empty when the module wasn't actually loaded into $PSMODULEPATH for this run. Either way, tar silently exits non-zero without producing the standard "Cache saved" closing message that the other 3 caches emit.

Workaround in our repo (works around but doesn't fix)

Adding cache-dependencies: false to both sign steps disables all 4 internal actions/cache@v5.0.4 invocations. Confirmed: subsequent dry-runs are all-green. Trade-off: ~30s additional wall-clock per workflow run from re-downloading the NuGet packages instead of restoring from cache. For our use case the trade-off is acceptable.

Suggested fix

Either:

1. Per-cache opt-out: introduce inputs like cache-trusted-signing-module: false so users can disable only the failing cache while keeping the NuGet caches active.
2. Diagnose & fix the TrustedSigning PSModule cache step: investigate why its tar invocation fails silently on github-hosted Windows runners. Possibly add if: hashFiles(…) != '' or continue-on-error: true guards to the cache step internally.
3. Skip the cache step entirely when the path doesn't exist, same as the SignCli case earlier in the post-steps (which uses the Path Validation warning path).

Context

Related issues observed during triage:

• Caching issue with TrustedSigning #98 (open, ~5 months stale) — different failure mode but same "cache layer is fragile" category.
• Internal actions/cache usage still runs on Node 20 and triggers deprecation warnings #125 (closed) — confirms internal cache infrastructure has been under-maintained.

Happy to provide the full workflow run logs if helpful — let me know what additional context would help.

[Jaxelr]

hey @asaffulks thanks for reporting this, ill take a look.

[Jaxelr]

hey @asaffulks bear with me as ive been swamped and havent been able to reach this.