fix(ci): produce .tar.gz archives for Zed ACP registry compatibility

[vincenzopalazzo]

Summary

• Adds .tar.gz archive output alongside the existing .tar.bz2 for Linux/macOS CLI builds
• Updates all release workflows (release, nightly, canary) to include goose-*.tar.gz in published artifacts

Problem

Zed's agent server store (agent_server_store.rs) only supports .tar.gz, .tgz, and .zip when downloading agent binaries:

let asset_kind = if archive_url.ends_with(".zip") {
    AssetKind::Zip
} else if archive_url.ends_with(".tar.gz") || archive_url.ends_with(".tgz") {
    AssetKind::TarGz
} else {
    anyhow::bail!("unsupported archive type in URL: {}", archive_url);
};

Goose currently only publishes .tar.bz2 for Linux/macOS, causing Zed users to get "unsupported archive type in URL" when installing Goose via the ACP registry.

Solution

Produce both .tar.bz2 (backward compat) and .tar.gz (Zed compat) in the build pipeline. This is a minimal change — one extra tar command in build-cli.yml and glob additions in the release workflows.

Once merged and released, the ACP registry entry for Goose can be updated to point to the .tar.gz URLs.

Test plan

• Verify CI builds produce both .tar.bz2 and .tar.gz artifacts
• Verify release assets include both archive formats
• After ACP registry update, verify Zed can install Goose via registry method

Closes #8047

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7ed8b43552

ℹ️ 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".

[DOsinga]

CI workflow fixes look good — the .tar.gz archives are a clean addition for Zed/ACP registry compatibility.

Changes pushed to the branch:

• Renamed ARTIFACT → ARTIFACT_ZIP in the Windows packaging step so all three upload-artifact path variables are consistently named and no empty entries are passed on either platform
• Removed the comment in the Linux/macOS packaging step that just restated what the tar commands do
• Added goose-*.tar.gz to the Attest build provenance subject-path in both canary.yml and release.yml so the new archives are covered by SLSA provenance signatures

[aleclarson]

Note that tar.bz2 is supported by the ACP registry:
https://github.com/agentclientprotocol/registry/blob/e77c08070ae89d4e76a0169021bf9974ca2ca51c/agent.schema.json#L96

So I would consider this a bug in Zed's implementation, FWIW.

[vincenzopalazzo]

Hey @aleclarson, good catch! You are right, the ACP registry schema does support .tar.bz2 — but looking at the Zed codebase, there is no handler for it.

The archive URL matching in agent_server_store.rs only handles .zip, .tar.gz, and .tgz — anything else bails with "unsupported archive type".

The AssetKind enum in github.rs has no TarBz2 variant, and the extraction logic in github_download.rs has no bzip2 decoder at all.

So yeah, producing both formats here is the pragmatic fix — it unblocks Zed users now. Might be worth opening an issue on zed-industries/zed to close this gap on their side too.

[vincenzopalazzo]

In the meantime, I also fixed the zed bug zed-industries/zed#52188, so now with the zed fix, we should have the full workflow completed