Fix self-update: download tarball and extract binary#198
Conversation
The release workflow uploads `clickhousectl-{target}-v{version}.tar.gz`
archives, but `update.rs` looked for a raw binary asset named
`clickhousectl-{target}` and wrote the response bytes directly to disk.
This meant `chctl update` always failed with "No compatible binary found
for this platform", and would have clobbered the running binary with a
gzipped tarball if the name had matched.
Build the asset name from `release.tag_name` to match the workflow, then
stream the download through `GzDecoder` + `tar::Archive` and pull out
the `clickhousectl` entry before the atomic rename.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
|
|
Nice fix — diagnosis and approach match what I had in #199 (which I've now closed in favour of this), and your per-step error messages + negative test are better than what I wrote. One small suggestion: the four For context: I'll open a separate small PR on top of this with the version bumps ( |
|
good call, i can change those real quick |
The download has already succeeded by the time we enter extract_binary_from_archive, so failures here are about parsing the tarball, not fetching it. Error::Extract already exists in error.rs with an "Extraction failed: ..." prefix that surfaces this clearly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bumps clickhousectl, clickhouse-cloud-api (and the dep reference between them), and npm/package.json to 0.2.2 in lockstep ready for release. CLAUDE.md now reflects this as the policy: previously it said clickhouse-cloud-api should only be bumped when its source changed and npm/package.json was bumped automatically by the workflow. Going forward, all three bump together at release time so the source-of- truth matches the tag. Stacked on ClickHouse#198, which contains the actual `chctl update` fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 participants
The release workflow uploads
clickhousectl-{target}-v{version}.tar.gzarchives, butupdate.rslooked for a raw binary asset namedclickhousectl-{target}and wrote the response bytes directly to disk. This meantchctl updatealways failed with "No compatible binary found for this platform", and would have clobbered the running binary with a gzipped tarball if the name had matched.Build the asset name from
release.tag_nameto match the workflow, then stream the download throughGzDecoder+tar::Archiveand pull out theclickhousectlentry before the atomic rename.closes #196