`v0.2.0` has zero release assets, and it's permanent - nothing can add them retroactively.
Root cause: GitHub's Immutable Releases feature (GA Oct 2025) is enabled on this repo. Confirmed via the API directly:
```
gh api repos/rubyists/linear-cli-ex/releases --jq '.[] | {tag: .tag_name, immutable: .immutable}'
{"tag":"v0.2.0","immutable":true}
{"tag":"v0.1.2","immutable":false}
```
Once a published release exists with this setting on, assets can never be added/changed/removed (docs). Our pipeline has release-please publish the release immediately, then spends ~10 minutes cross-compiling Burrito targets before `gh release upload` runs - by then the release is already locked, and the upload 422s (`Cannot upload assets to an immutable release`).
Fix (the documented workaround): create the release as a draft, upload every asset while still a draft, then publish it.
- `.release-please-config.json`: `"draft": false` -> `"draft": true`
- `burrito-release.yaml`: publish (`gh release edit --draft=false`) as the final step, after binaries + `SHA256SUMS` upload succeeds
Bonus fix this gets for free: previously a half-built release was visible/"latest" with zero assets for the whole ~10-minute build window even without the immutability bug - drafts aren't visible until published, so that window disappears too.
`v0.2.0` itself can't be repaired - a genuinely new release is needed after this lands to get real, installable assets (relevant for CRY-37, the Homebrew tap, which needs real assets to pin a sha256 against).
`v0.2.0` has zero release assets, and it's permanent - nothing can add them retroactively.
Root cause: GitHub's Immutable Releases feature (GA Oct 2025) is enabled on this repo. Confirmed via the API directly:
```
gh api repos/rubyists/linear-cli-ex/releases --jq '.[] | {tag: .tag_name, immutable: .immutable}'
{"tag":"v0.2.0","immutable":true}
{"tag":"v0.1.2","immutable":false}
```
Once a published release exists with this setting on, assets can never be added/changed/removed (docs). Our pipeline has release-please publish the release immediately, then spends ~10 minutes cross-compiling Burrito targets before `gh release upload` runs - by then the release is already locked, and the upload 422s (`Cannot upload assets to an immutable release`).
Fix (the documented workaround): create the release as a draft, upload every asset while still a draft, then publish it.
Bonus fix this gets for free: previously a half-built release was visible/"latest" with zero assets for the whole ~10-minute build window even without the immutability bug - drafts aren't visible until published, so that window disappears too.
`v0.2.0` itself can't be repaired - a genuinely new release is needed after this lands to get real, installable assets (relevant for CRY-37, the Homebrew tap, which needs real assets to pin a sha256 against).