CLI

Install

Download it from the latest release of my-beast/cli into a folder on your PATH:

mkdir -p ~/.local/bin
curl -fsSLo ~/.local/bin/mybeast-deploy https://github.com/my-beast/cli/releases/latest/download/mybeast-deploy
chmod +x ~/.local/bin/mybeast-deploy
mybeast-deploy --version

In CI, pin a release instead of latest: https://github.com/my-beast/cli/releases/download/v0.1.0/mybeast-deploy. See Deploy from CI.

Check the download

Each release lists its files' SHA-256 sums in SHA256SUMS. To check the file against them:

cd ~/.local/bin && curl -fsSL https://github.com/my-beast/cli/releases/latest/download/SHA256SUMS | grep ' mybeast-deploy$' | shasum -a 256 -c -

It prints mybeast-deploy: OK, or ends with an error when the file is not the one released.

Settings

Export them, or write them into the settings file as NAME=value lines (export and quotes are allowed). A variable that is exported wins over the file. With XDG_CONFIG_HOME set, the file is in that folder instead of ~/.config.

The file is read, never run, and refused while anyone but you can read it: chmod 600 it. The key goes to curl on its standard input, never on a command line where other users' ps would see it.

Commands

Run them from the app's folder: its git checkout says the commit.

Flags

A flag's value may also follow an equals sign, as in --app=shop. Flags go before --; everything after it belongs to your command.

What it sends

When a deploy starts:

• the app, the environment, and whether it is a deploy or a rollback;
• the command as it is shown, with the value of anything that looks like a secret taken out;
• the commit, its subject and the branch, whether the checkout had uncommitted changes, and for a deploy the checkout's last 50 commits (hash, author, subject);
• git's user.name and user.email, the machine's name and the system user;
• its own version, and the release named by --release or --to.

While it runs, your command's output, every 2 seconds, in batches of whole lines up to 256 KB, colours and all. With no new output it says it is still there every 30 seconds. A batch whose answer was lost is sent again and kept once. At the end: how it ended, the exit code and how long it took.

It never sends the key to your command, and never what you type at your command's prompts: those go from the terminal to the command. See Data and privacy.

The command's environment

Your command runs with the terminal, so its prompts work as without mybeast-deploy. Its output and its errors both go to the terminal at once and to the log. Ctrl-C goes to the command: its own clean-up runs, and the deploy is reported as stopped. It finds these variables beside your own:

MYBEAST_DEPLOYS_KEY is taken out of the command's environment.

When the service is down

Deploys being unreachable never stops a deploy. mybeast-deploy says what happened instead:

• not reported: … - the command runs all the same: the start was refused or never arrived. The command runs unreported, and the line says why.
• the log did not all reach the service: the whole log is kept on the machine, in $TMPDIR/mybeast-deploy-<id>.log.
• how it ended was not reported: Deploys marks the deploy lost after 10 minutes with no word.

Exit codes

Try it

The CLI's repository has two demo scripts in deploy/examples that talk like a real deploy and deploy nothing: --fail makes the deploy fail, and --ask asks for a deploy password first.

git clone https://github.com/my-beast/cli.git && cd cli/deploy
./mybeast-deploy run --app demo --env staging -- examples/demo-deploy.sh
./mybeast-deploy run --app demo --env staging -- examples/demo-deploy.sh --fail
./mybeast-deploy rollback --app demo --env staging -- examples/demo-rollback.sh

They report to your project like any deploy: --app demo adds an app called Demo, which counts toward your package's apps and keeps its history. Don't run them as a real app, whose page would then show a demo release as live.