Add `--arch` to `snapcraft close`, so a channel can be closed for specific architectures only: ``` snapcraft close my-snap stable --arch amd64 ``` The store API can't close a channel per architecture; `POST /dev/api/snaps/<id>/close` only takes a list of channels. The snapcraft.io web UI works around this in `closeRevision`: it closes the channel and then releases the revisions of the other architectures to it again. This PR does the same from the CLI. `--arch` can be repeated. Without it, `close` behaves as before. Before changing anything, the command reads the channel map and refuses when: - a requested architecture has no release in the channel - a revision that should be kept is also built for an architecture being closed, because releasing it again would bring that architecture back - a kept architecture has a progressive release in progress Before closing, it prints the revisions it will release again, so they can be restored by hand if a release fails partway. The progressive check comes from a real failure. I had a 10% progressive release on `stable` and closed one architecture through the web dashboard. The other architecture's newer revision was released again without its progressive settings, so `stable` went to 100% of the new version. Releasing a progressive revision again would also pick a new random set of devices and drop a paused state, so the command refuses instead of trying to rebuild the rollout. Users have asked for this on the forum many times, and the only answer has been to close the whole channel and release the wanted revisions again by hand: - https://forum.snapcraft.io/t/7517 - https://forum.snapcraft.io/t/10510 - https://forum.snapcraft.io/t/28405 - https://forum.snapcraft.io/t/29002 - https://forum.snapcraft.io/t/34031 ### Open questions - **A store API for this.** Closing and releasing again leaves the channel briefly closed for the other architectures too. A store endpoint that unreleases a single architecture from a channel would avoid that, and would let both the CLI and the dashboard drop the workaround. Is that something the store team could add? - **The dashboard bug.** On load, `getReleaseDataFromChannelMap` in snapcraft.io keeps only the first channel-map entry per channel and architecture, so during a progressive release it drops one of the two revisions. `closeRevision` then releases the kept revision again without its progressive settings. Should snapcraft.io refuse in the same cases as this PR? I also added a "Close a channel" section to the how-to on managing revisions and releases, which didn't cover `snapcraft close` yet. --- - [x] I've followed the [contribution guidelines](https://github.com/canonical/snapcraft/blob/main/CONTRIBUTING.md). - [x] I've signed the [CLA](http://www.ubuntu.com/legal/contributors/). - [x] I've successfully run `make lint && make test`. - [x] I've added or updated any relevant documentation. - [x] In documents I changed, I [added a meta description](https://canonical-starflow.readthedocs-hosted.com/how-to/add-a-page-meta-description/) if one was missing. - [ ] I've updated the relevant release notes. 🤖 Generated with [Claude Code](https://claude.com/claude-code)