Pin the Sume CLI to a release tag in CI and check for updates

Install a fixed sume binary from GitHub Releases, verify checksums.txt, and run sume update --check to see a newer release without changing files.

5 min readSume
All posts

To pin the Sume CLI in CI, download the sume-linux-x64 asset from a specific GitHub Release tag, check it against the release's checksums.txt, and install it yourself instead of piping the hosted installer. Then run sume update --check in a scheduled job to learn that a newer release exists without touching the binary.

This matters most for pipelines that watch long renders. A 30-second Seedance 2.5 or Wan 3.0 job can run for minutes, so CI often finishes with sume jobs watch and sume jobs download, and you want that behavior to stay the same until you choose to change it.

Why not just curl the installer

The hosted installer fetches the latest release for your OS and architecture, compares the binary with checksums.txt, and installs sume in ~/.sume-com/bin. That is the recommended path for people. For CI, the latest release changes under you between runs.

The docs describe a direct fallback for exactly this: release assets are named sume-darwin-arm64, sume-darwin-x64, sume-linux-arm64, sume-linux-x64, and sume-windows-x64.exe, each release carries checksums.txt, and you replace latest in the URL with a tag such as v0.1.6 for a pinned install (CLI install).

A pinned install step

This script installs one tag and fails if the checksum does not match. Set SUME_CLI_TAG in your pipeline variables. Replace the tag with one you have tested.

set -euo pipefail
TAG="${SUME_CLI_TAG:-v0.1.6}"
BASE="https://github.com/sumelabs/cli/releases/download/$TAG"
ASSET="sume-linux-x64"
cd "$(mktemp -d)"
curl -fsSL "$BASE/$ASSET" -o "$ASSET"
curl -fsSL "$BASE/checksums.txt" -o checksums.txt
grep " $ASSET\$" checksums.txt | sha256sum -c -
chmod +x "$ASSET"
sudo mv "$ASSET" /usr/local/bin/sume
sume version
sume doctor --agent --json

Check for updates without changing files

sume update --check shows whether a newer GitHub Release exists and does not change local files. Run it on a schedule and open a ticket when it reports one. When you decide to upgrade, bump SUME_CLI_TAG after a test run, or run the hosted installer again on a developer machine.

The command is listed under read commands in the command reference, next to sume version and sume doctor --agent --json.

What stays the same across versions

CLI behavior to keep stable in CI, Sume docs read 2026-10-05
CommandUse in a long-render pipeline
sume jobs watch <job_id>Poll until terminal or a timeout
sume jobs download <job_id> --output-dir ./outWrite completed media artifacts
sume jobs cancel <job_id> --confirm-submitCancel before generation starts
sume update --checkSee a newer release, change nothing

Two limits to remember

The CLI has no Image, Video or Music generator subcommands. Submit the render with the API, for example POST /v1/videos, and use the CLI to recover and download. Also, jobs watch timing out does not cancel the job, so read the stored job id again rather than submitting a second paid render.

A note on the checksum line

The docs say each release has a checksums.txt but do not show its layout. The grep and sha256sum -c above assume the usual one-line format of a hash, whitespace, then the file name. Open the file for your tag once and confirm it before you rely on the step.

Windows runners

On Windows, the hosted installer is irm https://cli.sume.com/install.ps1 | iex, and the pinned asset is sume-windows-x64.exe. The same rule applies: pin a tag in CI and use the hosted installer on developer machines.

What to log in CI

Print sume --version at the start of every job that touches a paid render. When a failure appears after a CLI bump, the version in the log tells you at a glance whether the change was the cause.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume