GitHub Actions and Sume: secret setup and a smoke test

Add SUME_API_KEY as a repository secret, map it into the step's environment, and run sume account get --json as a read-only check. The GitHub changelog lists stateless GitHub App installation tokens rolling out on Oct 2, 2026, and Actions retention now covering checks, runs and statuses as of Oct 1, which makes it more important to keep secrets out of logs.

Setup

Create a key in the Sume API Keys dashboard, then add it under the repository's Actions secrets. The CLI docs say never to print or commit SUME_API_KEY, the local config file or raw provider payloads, and to use environment variables or a secret manager for automation.

A smoke-test workflow

The workflow installs the CLI with the hosted installer, which places sume under ~/.sume-com/bin, then reads the account with output sent to /dev/null, so nothing sensitive reaches the log:

name: sume-smoke
on: workflow_dispatch
jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - name: Install Sume CLI
        run: curl https://cli.sume.com/install -fsS | bash
      - name: Check the key
        env:
          SUME_API_KEY: ${{ secrets.SUME_API_KEY }}
        run: |
          "$HOME/.sume-com/bin/sume" account get --json > /dev/null
          echo "Sume key accepted"

Keep CI from spending money

Keep the smoke test read-only. The CLI gates paid Avatar runs behind --confirm-paid, and the docs advise submitting one bounded job first when testing and recovering existing jobs instead of blindly retrying paid commands.

• Trigger by hand with workflow_dispatch while you test
• Do not pass --confirm-paid in a smoke test
• Do not echo the key or the account response
• Rotate the key if it ever appears in a log

Going beyond the smoke test

Image, video and music calls are API-first, so apply the same confirmation habits in your HTTP client. A workflow that submits paid jobs should use an Idempotency-Key per job and record the job id as an artifact, so a re-run recovers the job instead of paying twice.