download-artifact@v4 silently warned on digest mismatches, which hid the
corrupt `kilo-cli` download on run 25101862100 until the next step
failed with "CLI binary not found". v8 defaults `digest-mismatch`
to `error`, so the same failure surfaces on the download step itself
with an actionable message.
Also switches the build-cli upload to upload-artifact@v7's
`archive: false`, so the already-zstd'd tarball travels as-is instead
of being re-wrapped in a store-only zip. With `archive: false` the
`name:` input is ignored and the artifact is named after the file
(`kilo-cli.tar.zst`), so the two consumers (build-vscode, publish)
now reference `name: kilo-cli.tar.zst` and set `skip-decompress: true`.
The `kilo-vscode` upload stays on v4: it uploads a directory of .vsix
files and `archive: false` requires a single file.
Uncompressed tar left the artifact at ~2.7 GB (same as no-compression
zip on the previous attempt). zstd compresses the tree-sitter wasms
~4x while being near-native speed on the already-compact binaries,
which should bring the artifact close to ~1 GB.
zstd 1.5.7 and GNU tar 1.35 are preinstalled on both github-hosted
and blacksmith ubuntu-2404 images (per the actions/runner-images
Ubuntu2404 manifest and blacksmith's drop-in-replacement docs).
Already used in this same workflow by actions/cache@v4 for bun pm
cache restoration, so availability is empirically confirmed.
The prior shrink-artifact PR (#9671) didn't prevent the build-vscode
failure on run 25101862100. Artifact grew to 2.7 GB (compression-level: 0
stores uncompressed) and the ~36-minute download still hit the v4 action's
per-entry unzip bottleneck, leaving the cli-linux-x64 binary missing.
actions/download-artifact@v4 pipes the response through Node's
unzip-stream and writes each entry to disk sequentially on a single
thread. With ~480 entries per target x 12 targets the per-entry overhead
dominates total download time.
Collapsing everything into a single tar before upload reduces the
artifact to one zip entry, eliminates the per-file overhead, and lets
native 'tar -xf' do the actual extraction on the consumer side.
References:
- actions/upload-artifact#36 (canonical tracking issue)
- actions/toolkit#1533 (5000 files: 18m -> 22s with pre-tar)
- actions/download-artifact#362 (download speed investigation)
The kilo-cli artifact ballooned from ~1 GB to 1.83 GB after the codebase
indexing PR started emitting external sourcemaps and copying tree-sitter
wasms per target. The resulting 1.83 GB artifact triggered a silent
partial-extract in actions/download-artifact@v4 during build-vscode,
causing the 2026-04-29 publish run to fail with 'CLI binary not found'.
- Skip external sourcemaps in release builds (~620 MB saved across
12 targets); dev builds still emit maps for local debugging.
- Exclude any stray .map files from the CI artifact and skip zstd
compression on binaries (saves ~60 s on upload and reduces the
chance of partial-extract bugs on the download side).
Refs: PR #6966 (commit f74d54c4), run 25096325401
Prettier pads markdown table cells for column alignment, which turns any
content change into a table-wide realignment diff. Markdown was only in
prettierignore for packages/kilo-vscode/; the root formatter still
repadded docs elsewhere (e.g. TESTING.md, kilo-docs, AGENTS.md).
Adds *.md to the root .prettierignore, documents the convention in
AGENTS.md, and adds script/check-md-table-padding.ts + a workflow to
enforce it. Existing padded tables in Kilo-owned docs have been
rewritten via the script's --fix mode.
Addresses review feedback: `gh api | head -n1` can fail under bash
pipefail because head closes the pipe early and SIGPIPEs gh api. The
tag_name + asset-name filter already returns a single URL, so drop
--paginate and the head pipe.
Fixes Kilo CLI install failing with curl exit 22 when the smoke-test
workflow runs as a pre-publish gate. The browser download URL
(github.com/.../releases/download/...) 404s on draft releases, so
look up the asset via the releases API and let the installer use the
API URL with Accept: application/octet-stream and bearer auth.
Also bumps smoke-test.yml permissions to contents: write so the job
token can see draft releases, and re-enables the smoke-test job in
publish.yml.
The version job ran `bunx changeset version` to consume .changeset/*.md
files and update CHANGELOG.md, but the publish job (which commits and
pushes) ran on a separate runner with a fresh checkout — discarding all
changelog changes. This caused CHANGELOG.md to stay stuck at 7.2.1
despite 9 subsequent releases.
Move changeset consumption into publish.ts so it runs on the same runner
that commits. Extract release notes from the updated changelog and pass
them to `gh release edit` so GitHub releases also get correct notes.
kiloconnect[bot]