fix(installer): drop -L in resolve_version, parse first-redirect Location (AL-31)#19
Merged
Merged
Conversation
…tion (AL-31)
Fifth dogfood-discovered bug, surfaced during the v0.3.2-rc2 retest.
`packaging/curl-installer/install.sh:111` (pre-fix) read the latest tag via
`curl -fsSIL -o /dev/null -w '%{url_effective}'` against
`/releases/latest/download/VERSION`. With `-L`, curl followed the entire
redirect chain to the final `release-assets.githubusercontent.com` URL,
which contains opaque tokens but NOT the tag string. The grep returned
empty and the installer died with `could not parse tag from redirect URL`.
The tag IS in the FIRST hop (`releases/latest/download/VERSION` 302→
`releases/download/<TAG>/VERSION`), but `%{url_effective}` after `-L`
reports only the LAST URL.
**Fix**: drop `-L`, switch the write-out template to `%{redirect_url}`
which prints the next-hop Location header without following. Confirmed
locally — `redirect_url=https://github.com/Roo4L/Agent-Linux/releases/
download/v0.3.1/VERSION`, tag extraction yields `v0.3.1` cleanly.
Also tightens the diagnostic message: when no Location header arrives
(server returned 200 instead of 302), the die output now hints
`set AGENTLINUX_VERSION to override` rather than asking the user to
parse an empty redirect URL.
**Test guard**: `tests/bats/60-curl-installer.bats` gains a new INST-03
@test that performs three source-shape assertions on `install.sh`:
1. `%{redirect_url}` is used somewhere in a curl invocation
2. `%{url_effective}` is NOT used in resolve_version() code (comments
allowed — the explanatory comment legitimately mentions both)
3. resolve_version's curl call carries no -L flag
This is a static guard, not a behavior test — exercising the live
redirect path requires a 302→302 fixture chain or an env-var seam to
override the hardcoded github.com URL, neither of which exists today.
The shape guard prevents the specific regression class without
requiring a fixture rewrite. Future PR can add a behavior fixture if
resolve_version grows.
Workaround for users on pre-AL-31 builds: `export AGENTLINUX_VERSION=...`
before piping. Documented in the v0.3.2-rc2 dogfood instructions
(.planning/quick/260503-dtx-...-SUMMARY.md).
Refs: AL-18, AL-21 (parent retest), AL-30 (the four-bug fix that
surfaced this), AL-31.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
pnpm v11 (released between 2026-05-03 and 2026-05-09) elevated the "ignored build scripts" warning to a hard `ERR_PNPM_IGNORED_BUILDS` error. Corepack auto-fetches the latest pnpm absent a `packageManager` field, so every fresh install today picks up v11 and dies on the unconfigured `@biomejs/biome` postinstall script. Two paired changes: 1. `plugin/cli/package.json` gains a `packageManager: pnpm@10.18.2` field. Corepack honors this pin, so CI installs deterministically pull pnpm 10.x regardless of upstream releases. v10.18.2 was the pnpm version that produced the green CI runs landed on master on 2026-05-03, so this is bisect-clean. 2. `plugin/cli/pnpm-workspace.yaml` (new) adds an `onlyBuiltDependencies` allowlist for `@biomejs/biome`. This is the v10/v11-compatible format pnpm itself emits as a template when an unconfigured build script is detected. Belt-and-suspenders: when we later relax the pin to v11+, the install no longer dies because the script is pre-approved. Verified locally: `corepack pnpm install --frozen-lockfile` produces `Done in 626ms using pnpm v10.18.2` cleanly. No `ERR_PNPM_IGNORED_BUILDS`. This commit rides with the AL-31 fix because it blocks AL-31's CI from ever going green; without it, the AL-31 PR cannot land. Splitting it into a separate PR would just create a serialization hazard for zero benefit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fifth dogfood-discovered bug from the v0.3.2-rc2 retest. Unpinned
curl ... | bash(noAGENTLINUX_VERSION) dies with "could not parse tag from redirect URL" becauseresolve_version()follows ALL redirects to the finalrelease-assets.githubusercontent.comURL, which contains opaque tokens but no tag.Fix
packaging/curl-installer/install.sh:111-117:-Lflag.%{redirect_url}instead of%{url_effective}.The first redirect hop is always
releases/latest/download/<asset>→releases/download/<TAG>/<asset>, which carries the tag. The second hop intorelease-assets.githubusercontent.comdoes not — that's why-Lfollowed by%{url_effective}lost the tag.Confirmed locally against the live GitHub redirect:
redirect_urlevaluates tohttps://github.com/Roo4L/Agent-Linux/releases/download/v0.3.1/VERSION, tag extraction yieldsv0.3.1cleanly.Test guard
New
INST-03@testintests/bats/60-curl-installer.bats. Source-shape assertions:%{redirect_url}is used in a curl invocation.%{url_effective}is NOT used inresolve_version()code (comments allowed).resolve_version's curl call carries no-Lflag.This is a static guard, not a behavior test — exercising the live redirect path requires either a 302→302 fixture chain or an env-var seam to override the hardcoded github.com URL, neither of which exists today. Shape guard is sufficient to prevent the regression class.
Why not a behavior test (yet)
The single-fixture python http server in
60-curl-installer.bats:setup_fileonly serves static files. Adding a 302→302 chain requires a custom python server script, ANDresolve_version()'s URL is hardcoded togithub.com/${ORG}/agent-linux/...with no env-var override seam. Two separate enhancements; outside this PR's scope. AL-29 may want to revisit if it touchesresolve_version.Test plan
gate-1-precommitgate-2-docker × {22.04, 24.04, 26.04}— the new@testasserts on the actual file shipped in the tarballgate-3-qemu × {22.04, 24.04}curl ... | bash(noAGENTLINUX_VERSION) against the next published RCRefs: AL-18, AL-21, AL-30, AL-31