Summary
Two workflows download the asciinema binary from a GitHub releases/latest/download URL, which always redirects to whatever the newest release happens to be. The binary is fetched fresh on every run, so an upstream release changes what executes in CI with no commit, no review, and no record of which version produced the committed recordings.
Details
.github/workflows/vortex-release.yml line 240 and .github/workflows/vortex-test-installer.yml line 83, both inside the "Generate video for installer" step:
sudo curl -sSL https://github.com/asciinema/asciinema/releases/latest/download/asciinema-x86_64-unknown-linux-gnu -o /usr/local/bin/asciinema && sudo chmod +x /usr/local/bin/asciinema
asciinema records the terminal demo videos under .vortex/docs/static/img/, and its output is committed. A recording-format change between asciinema versions therefore lands as a diff in generated assets rather than as an obvious failure, and the two workflows can pick up different versions from each other depending on when each runs.
releases/latest/download is a stronger form of the same problem as an untagged container image: there is not even a local cache to make consecutive runs agree.
Suggested resolution
Replace latest with an explicit release tag in both workflows, keeping the two in lockstep, and verify the checksum of the downloaded binary. Renovate's github-releases datasource can track a pinned tag in a URL through a customManagers regex, so the pin does not have to rot.
Related
Found while auditing for unpinned tool versions after the hadolint incident in #2868. The sharp-cli install in the same step has the same problem and is tracked separately, since the remediation differs.
Summary
Two workflows download the
asciinemabinary from a GitHubreleases/latest/downloadURL, which always redirects to whatever the newest release happens to be. The binary is fetched fresh on every run, so an upstream release changes what executes in CI with no commit, no review, and no record of which version produced the committed recordings.Details
.github/workflows/vortex-release.ymlline 240 and.github/workflows/vortex-test-installer.ymlline 83, both inside the "Generate video for installer" step:sudo curl -sSL https://github.com/asciinema/asciinema/releases/latest/download/asciinema-x86_64-unknown-linux-gnu -o /usr/local/bin/asciinema && sudo chmod +x /usr/local/bin/asciinemaasciinemarecords the terminal demo videos under.vortex/docs/static/img/, and its output is committed. A recording-format change between asciinema versions therefore lands as a diff in generated assets rather than as an obvious failure, and the two workflows can pick up different versions from each other depending on when each runs.releases/latest/downloadis a stronger form of the same problem as an untagged container image: there is not even a local cache to make consecutive runs agree.Suggested resolution
Replace
latestwith an explicit release tag in both workflows, keeping the two in lockstep, and verify the checksum of the downloaded binary. Renovate'sgithub-releasesdatasource can track a pinned tag in a URL through acustomManagersregex, so the pin does not have to rot.Related
Found while auditing for unpinned tool versions after the
hadolintincident in #2868. Thesharp-cliinstall in the same step has the same problem and is tracked separately, since the remediation differs.