Sign in

ase acts as you, in your studio, with your role. On your machine you sign in once with a code. In CI, the job proves itself with a release credential instead.

On your machine

ase login

ase prints a link and a short code. Open the link, sign in to the studio console as you usually do, check that the code matches and choose Approve. ase then holds a session for 12 hours, with the studio and role you had when you approved it.

ase studio whoami   # your studio, role and permissions, as the console has them now
ase logout          # forget the session on this machine

The session is stored in session.json in your config folder, readable only by you:

Set ASE_CONFIG_HOME to use another folder.

ase checks the session with ASE Brain before each command, so a session your studio revoked stops working at once. If ASE Brain can't be reached, a session that was valid keeps working for up to an hour.

Working offline

Developing a game never stops at the sign-in. ase editor, ase sdk ensure, ase sdk apply and ase sdk status work without a sign-in or a network, using the SDK already on your machine. They tell you why they're offline. Only a project that needs an SDK version you haven't downloaded yet is blocked.

In CI

A CI job has no session. It proves which studio it works for with a release credential, which ase reads in this order:

1. ASE_RELEASE_KEY: a release key from ase studio key.
2. ASE_BRAIN_ID_TOKEN: an OIDC token your CI puts in the environment, such as GitLab's id_tokens.
3. GitHub Actions' own OIDC token, when the job has permissions: id-token: write.

Tokens are minted for the audience https://asebrain.com.

GitHub Actions

Trust your studio's GitHub Actions once:

ase studio trust --preset github

From then on, any run on main of a game's own repo can release that game. Use --branch to trust another branch. The workflows ASE Brain keeps in your repo already ask for id-token: write.

GitLab CI

ase studio trust --preset gitlab
ase studio trust --preset gitlab --issuer https://gitlab.example.com   # self-hosted

Then give the job a token:

release:
  id_tokens:
    ASE_BRAIN_ID_TOKEN:
      aud: https://asebrain.com
  script:
    - ase release publish --game neon-drift --version 1.2.0 --target brain --builds builds --notes notes.md

Any other CI

Make a release key and store it as the job's ASE_RELEASE_KEY secret:

ase studio key ci

ase prints the key once. ASE Brain keeps only its hash, so store it straight away.

What a trust allows

A trust lets CI release only your studio's games, and each game only from its own repo. A run of one game's repo can't release another game, and a trust can never cover every repository on a host. Releasing still needs the trust: a credential alone proves which studio a job is for.

Pointing ase elsewhere

These are for testing against a local ASE Brain. You don't need them for normal use.

Each must be HTTPS, or HTTP on loopback.