Deploy from CI

An example job

A GitHub Actions job that deploys shop to production and reports it:

deploy:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 50
    - name: Deploy
      env:
        MYBEAST_DEPLOYS_URL: https://services.my-beast.com/deploys
        MYBEAST_DEPLOYS_KEY: ${{ secrets.MYBEAST_DEPLOYS_KEY }}
      run: |
        mkdir -p ~/.local/bin
        curl -fsSLo ~/.local/bin/mybeast-deploy https://github.com/my-beast/cli/releases/download/v0.1.0/mybeast-deploy
        chmod +x ~/.local/bin/mybeast-deploy
        git config user.name "${{ github.actor }}"
        ~/.local/bin/mybeast-deploy run --app shop --env production -- make deploy

Any other CI works the same way: download the file, set the two variables, and run your deploy command through mybeast-deploy run. It ends with your command's exit code, so the job fails when the deploy fails, reported or not.

Pin and check the release

In CI, download a fixed release instead of latest, so a new version arrives only when you change the line: https://github.com/my-beast/cli/releases/download/v0.1.0/mybeast-deploy. To check it against that release's checksums:

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

It ends with an error when the file is not the one released, so put it before the deploy.

The key

Keep the server key in your CI's secrets and hand it to the step as MYBEAST_DEPLOYS_KEY, with MYBEAST_DEPLOYS_URL beside it. mybeast-deploy never passes the key to your deploy command, so the command can't print it into the log.

When the project keeps its environment in Secrets, id may have put the key there already, and mybeast-secrets run -- mybeast-deploy run … hands it over without a file. The setup guide in Deploys says whether it's there.

Without a terminal

Give the command after --. Without one, mybeast-deploy runs the app's saved command only after a yes, and on a runner there's no terminal to ask in: it stops with exit code 2. Pass --yes to run the saved command without asking:

mybeast-deploy run --app shop --env production --yes

Your deploy script must not wait for an answer either, such as a password typed at a prompt.

Who it names

A deploy names who ran it from git's user.name and user.email. When the e-mail address is a My Beast person's, the deploy shows their name. A runner has neither as a rule, so the deploy names its system user instead, such as runner. Set them in the job, as the example does with the person who started it.

The machine is named by the runner's host name.

What it brings

A deploy sends the checkout's last 50 commits, and its page lists the ones since what was live. A shallow clone has only one, so the page can't tell what is new. Fetch at least 50 commits, as the example does with fetch-depth.

A checkout with changes that aren't committed is marked Uncommitted changes went along on the deploy's page. A build step that writes into tracked files does that too. See What it shipped.