Install standalone archives with checksum verification#18901
Install standalone archives with checksum verification#18901efrazer-oai wants to merge 2 commits into
Conversation
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.
Add fallback when checksum asset is missing for old releases
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.
Keep Windows installer compatible with pre-checksum releases
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.
5921501 to
f96b06b
Compare
f96b06b to
a45f5ce
Compare
a45f5ce to
a2cb4ee
Compare
3cb7390 to
85a00e8
Compare
a2cb4ee to
9c24168
Compare
9c24168 to
0f248b8
Compare
|
Closing this pull request because it has had no updates for more than 14 days. If you plan to continue working on it, feel free to reopen or open a new PR. |
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: installer shell syntax check, checksum parsing checks, a local fake-release Unix installer smoke covering checksum download, standalone archive download, verification, extraction, install, and visible
codex --version, plus a local handoff smoke where this installer consumed a standalone archive produced by #18910's staging script.