Installing a Beta
A beta train installs on metal the same way a release does — same two commands, same checksum verification, same layout. The only thing that changes is which URL you fetch the script from.
The ref you fetch is the channel. A script read off a pipe cannot see the URL it came from, so what it installs is decided by the copy of the file on that ref. There is no --channel option.
| Want | Fetch install.sh from |
Installs |
|---|---|---|
| the latest release | …/actana/control/main/install.sh |
the release of the line main carries |
| a specific release | …/actana/control/vX.Y.Z/install.sh |
that line's release. A release tag never moves, so this is a pin |
| the current beta of a line | …/actana/control/beta/X.Y/install.sh |
that line's current beta — or the newest release, if nobody has cut one yet |
| the same beta, by tag | …/actana/control/vX.Y.Z-beta/install.sh |
the same as the row above — an alias, not a pin |
install.sh --help names the line the copy you fetched carries. Which trains are open right now:
git ls-remote --heads https://github.com/actana/control | grep -i beta
A train with no cut yet falls through to the newest release, quietly. The script says so before it downloads: its first line is Installing the Actana Core <version> for <target>. A bare x.y.z where you expected x.y.z-beta is that fall-through.
curl -fsSL https://raw.githubusercontent.com/actana/control/beta/X.Y/install.sh | bash
actana setup
A beta version is x.y.z-beta, exactly. The beta of the X.Y line is X.Y.Z-beta. There is no counter, dotted suffix, run number, or short sha after the word beta. Anything with something appended after beta is not a version this project publishes, and --version will not find it.
A beta lands beside the release of its line (versions/x.y.z-beta), not on top of it. When the line promotes, the train branch is deleted — a beta/X.Y URL that 404s is the line having shipped; install the release from main.
The only way to pin a beta is --version
The two beta rows above are not pins. The vX.Y.Z-beta tag moves on every cut, and once the line has a release both rows install the release. The pinned form wins over everything:
curl -fsSL https://raw.githubusercontent.com/actana/control/main/install.sh | bash -s -- --version X.Y.Z-beta
actana setup
ACTANA_VERSION=X.Y.Z-beta does the same thing.
actana update does not follow a beta line. A bare update resolves the newest release and leaves a newer prerelease where it is. To take a newer cut of the same beta, re-run the one-liner from the train's ref. When that line's release is published, actana status says so; that update is what moves you onto it.
A CLI-only beta, without a Core
The npm registry carries releases only — @actana/cli never has a beta. The beta CLI ships on the GitHub release as an npm tarball:
npm install -g https://github.com/actana/control/releases/download/vX.Y.Z-beta/actana-cli-X.Y.Z-beta.tgz
Every release asset has a .sha256 beside it; verify before installing:
curl -fsSL https://github.com/actana/control/releases/download/vX.Y.Z-beta/actana-cli-X.Y.Z-beta.tgz.sha256 | shasum -a 256 -c -
actana --version should print x.y.z-beta. This installs the actana command only — no Core bundle, nothing running. A machine with the CLI and no actana setup is a pure client: it drives Cores elsewhere (a Docker Compose stack on this machine, or a remote Core) and never becomes a Core itself. The install.sh door above is the full-bundle door — it places the Core bundle too, and stops before actana setup activates it.
macOS stock bash
On macOS, curl … | bash can fail with asset…: unbound variable — the stock bash 3.2 mis-parses the script. Workaround in Troubleshooting.
