Summary
Two workflows install sharp-cli globally with no version constraint, so each run resolves whatever npm currently publishes as latest. A breaking sharp-cli release changes the documentation video output, or fails the step outright, on a commit that changed nothing.
Details
.github/workflows/vortex-release.yml line 241 and .github/workflows/vortex-test-installer.yml line 84, both inside the "Generate video for installer" step:
sharp-cli is used by .vortex/docs/.utils/update-videos.php to produce the PNG posters for the terminal demo videos. It is a build-time tool whose output is committed, so an unnoticed version change alters generated artifacts rather than failing loudly.
The two workflows must move together: if only one is pinned, the release workflow and the installer-test workflow generate posters with different tooling.
Suggested resolution
Pin the version in both workflows (npm i -g sharp-cli@<version>), keeping the two in lockstep.
Worth considering as an alternative: sharp-cli is only ever used from .vortex/docs, which already has a package.json and a committed yarn.lock. Moving it to a dev dependency there would pin it through the existing lockfile, put it under the Renovate rules that already govern that directory, and remove the global install from both workflows.
The same step also runs sudo apt install expect without a version. That is a distro package on a GitHub-managed runner image with a different risk profile, so it is noted here rather than tracked separately.
Related
Found while auditing for unpinned tool versions after the hadolint incident in #2868. The asciinema download in the same step has the same problem and is tracked separately, since the remediation differs.
Summary
Two workflows install
sharp-cliglobally with no version constraint, so each run resolves whatever npm currently publishes as latest. A breakingsharp-clirelease changes the documentation video output, or fails the step outright, on a commit that changed nothing.Details
.github/workflows/vortex-release.ymlline 241 and.github/workflows/vortex-test-installer.ymlline 84, both inside the "Generate video for installer" step:npm i -g sharp-clisharp-cliis used by.vortex/docs/.utils/update-videos.phpto produce the PNG posters for the terminal demo videos. It is a build-time tool whose output is committed, so an unnoticed version change alters generated artifacts rather than failing loudly.The two workflows must move together: if only one is pinned, the release workflow and the installer-test workflow generate posters with different tooling.
Suggested resolution
Pin the version in both workflows (
npm i -g sharp-cli@<version>), keeping the two in lockstep.Worth considering as an alternative:
sharp-cliis only ever used from.vortex/docs, which already has apackage.jsonand a committedyarn.lock. Moving it to a dev dependency there would pin it through the existing lockfile, put it under the Renovate rules that already govern that directory, and remove the global install from both workflows.The same step also runs
sudo apt install expectwithout a version. That is a distro package on a GitHub-managed runner image with a different risk profile, so it is noted here rather than tracked separately.Related
Found while auditing for unpinned tool versions after the
hadolintincident in #2868. Theasciinemadownload in the same step has the same problem and is tracked separately, since the remediation differs.