Install standalone archives with checksum verification#18901
Install standalone archives with checksum verification#18901efrazer-oai wants to merge 1 commit intoefrazer/standalone-installer-artifactsfrom
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5921501104
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| step "Downloading Codex CLI" | ||
| expected_digest="$(release_asset_digest "$asset" "$resolved_version")" | ||
| download_file "$(release_url_for_asset "codex-installer_SHA256SUMS" "$resolved_version")" "$checksums_path" |
There was a problem hiding this comment.
This now always downloads codex-installer_SHA256SUMS for the requested --release. Historical tags published before this workflow change will not contain that asset, so pinned installs fail early (404) even when the tarball exists. The previous path used release metadata and remained compatible with older versions.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Imo it's worth forcing installs past this point to require a checksum.
| Write-Step "Downloading Codex CLI" | ||
| Invoke-WebRequest -Uri $assetMetadata.Url -OutFile $archivePath | ||
| Test-ArchiveDigest -ArchivePath $archivePath -ExpectedDigest $assetMetadata.Sha256 | ||
| Invoke-WebRequest -Uri $checksumsUrl -OutFile $checksumsPath |
There was a problem hiding this comment.
The PowerShell installer now unconditionally fetches codex-installer_SHA256SUMS from the target release. Older release tags that predate this new asset will fail installation for explicit -Version/--release requests, even though the archive is present. A compatibility fallback is needed to avoid regressing pinned-version installs.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Same as above, but could be wrong. Will leave to @viyatb-oai and @bolinfest to decide.
efrazer-oai
force-pushed
the
efrazer/installer-checksums
branch
from
5921501 to
f96b06b
Compare
efrazer-oai
changed the title
efrazer-oai
changed the base branch from
main
to
efrazer/standalone-installer-artifacts
efrazer-oai
force-pushed
the
efrazer/installer-checksums
branch
from
f96b06b to
a45f5ce
Compare
1 participant
Summary
This PR changes the standalone installers to use the release files from #18910.
Before this change, the installers downloaded the npm tarball and reached into
package/vendor/...to find the native files. That made the installer depend on npm package internals.Now the installers download the standalone archive for the current platform, download
codex-installer_SHA256SUMS, verify the archive hash, and then unpack the archive into the managed standalone release directory.The install flow is:
codex-standalone-<platform>-<version>.tar.gzarchive.codex-installer_SHA256SUMS.This keeps npm packaging and standalone install packaging separate.
Stack
Tests
Tests: formatter check, installer syntax checks, checksum parsing smoke tests, and a local fake-release installer smoke covering checksum download, standalone archive download, verification, extraction, install, and visible
codex --version.