Skip to main content
Planned. This page describes designed behaviour that is not built yet. Details may change before it ships.
Your company’s CI builds every Gliss app. Gliss never builds your code itself. In GitHub Actions, the job runs the gliss-cli container, which runs Garden with the gliss provider, and holds no stored secrets: every credential it uses is short-lived and obtained during the run. Garden doesn’t document GitHub Actions directly, and its CircleCI guide assumes a kubeconfig and Garden Cloud, so this page describes the Gliss setup instead of porting it.

​
What a CI run does

  1. Builds and tests. Garden builds the images and runs the CI-side exec tests. Actions whose version hasn’t changed are skipped; see Caching.
  2. Pushes images to your registry. The job signs in to your company’s AWS account with GitHub Actions OIDC and pushes the images to Amazon ECR. That AWS role is for pushing to ECR only.
  3. Requests a release. The job exchanges a GitHub Actions OIDC token for a Gliss token, and asks Gliss to release the app. Gliss checks the request and the cluster agent applies it. CI never talks to your clusters and has no kubeconfig.

​
Credentials without stored secrets

Both sign-ins use the OIDC ID token that GitHub issues to the job, so the workflow needs permission to request one:
  • AWS: the job assumes a role in your AWS account through GitHub’s OIDC provider. Set that role up to allow pushes to your app’s ECR repositories and nothing else. See GitHub’s guide to configuring OpenID Connect in Amazon Web Services.
  • Gliss: the gliss provider sends the OIDC token to POST /api/gliss/v1/ci/token and gets back a Gliss token. The token lasts one hour, works only for the one app whose repository the run belongs to, and only lets the job request releases and read that app’s diagnostics. Nothing is stored in the repository or in GitHub secrets.

​
Which runs can request releases

Gliss decides from the claims in the OIDC token. By default:
  • only runs on main can get a token, and the branch must be protected;
  • only push and workflow_dispatch runs can get a token;
  • pull request runs never can, because they can run code or input from forks.
An admin can allow more branches or events for an app, or pin the token exchange to one workflow file or one GitHub deployment environment. Each GitHub OIDC token can be exchanged only once.

​
Learn more