GitHub Actions Overview

Quant Cloud provides a suite of official GitHub Actions to automate your deployment workflows. These actions work together to build, deploy and operate containerised applications.

Available Actions

Action	Purpose	Latest release	Commit SHA
Init	Validate access, log Docker in to the registry, detect the environment	v4.0.1	1bc52dca113ea1cb2f3d7dcb0edbc7859d76afaf
Compose	Validate and translate docker-compose.yml	v4.0.0	3a06db471e3364db3e4691fd522b9c37346d0a19
Environment	Create, update or delete environments	v4.0.0	936fe16373f3169fa15b61a9117ffa87b3996855
Environment Vars	Manage environment variables	v1.0.2	ce1ea37c9f7e9169c1c70df35ae3fe6f1111e2c9
Sync	Copy a database or files between environments	v4.0.0	aeb054d52e2067ac7eb6694c07df2c4cde262c5f
Backup	Create, list, download and delete backups	v4.4.2	9c46be7346ab2ec78f7dd5e0b0795ce2eff3eca2
State	Redeploy, stop or start an environment	v4.0.1	b1b75af5d772bb295bc067f225a7bb3a952bd7a1

The repositories are quantcdn/quant-cloud-<name>-action (for example quant-cloud-init-action). The separate quant-cloud-ecr-action is superseded by the Init Action. For static sites, use quantcdn/deploy-action and quantcdn/purge-action.

Typical Workflow Pattern

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      # 1. Initialize - validate access, log in to the registry, detect the environment
      - uses: quantcdn/quant-cloud-init-action@v4
        id: init
        with:
          quant_organization: ${{ secrets.QUANT_ORGANIZATION }}
          quant_api_key: ${{ secrets.QUANT_API_KEY }}
          base_url: ${{ vars.QUANT_BASE_URL || 'https://dashboard.quantcdn.io' }}

      # 2. Build and push images (Docker is already logged in by init).
      #    The tag starts with the compose service name, e.g. app-latest.

      # 3. Translate the compose file
      - uses: quantcdn/quant-cloud-compose-action@v4
        id: compose
        with:
          api_key: ${{ secrets.QUANT_API_KEY }}
          organization: ${{ secrets.QUANT_ORGANIZATION }}
          compose_file: docker-compose.yml
          image_suffix: ${{ steps.init.outputs.image_suffix_clean }}
          base_url: ${{ vars.QUANT_BASE_URL || 'https://dashboard.quantcdn.io' }}

      # 4. Create or update the environment, then redeploy an existing one (State Action)
      - uses: quantcdn/quant-cloud-environment-action@v4
        with:
          api_key: ${{ secrets.QUANT_API_KEY }}
          organization: ${{ secrets.QUANT_ORGANIZATION }}
          app_name: ${{ steps.init.outputs.quant_application }}
          environment_name: ${{ steps.init.outputs.environment_name }}
          operation: ${{ steps.init.outputs.environment_exists == 'true' && 'update' || 'create' }}
          compose_spec: ${{ steps.compose.outputs.translated_compose }}
          base_url: ${{ vars.QUANT_BASE_URL || 'https://dashboard.quantcdn.io' }}

The actions create environments, not applications. Create the application first in the dashboard or with the API.

QuantCDN and QuantGov

Every Quant Cloud action takes a base_url input. It defaults to QuantCDN. For QuantGov, set it on every Quant Cloud step:

Platform	base_url
QuantCDN	https://dashboard.quantcdn.io (default)
QuantGov	https://dash.quantgov.cloud

The v4 actions also accept the value with /api/v3 (https://dash.quantgov.cloud/api/v3). The Environment Vars Action (v1.0.2) accepts only the host without /api/v3; see its page. The API key belongs to one platform.

Secrets and variables

Name	Store as	Value
QUANT_API_KEY	Secret	An API token from your dashboard profile (API Tokens)
QUANT_ORGANIZATION	Secret	Your organisation machine name
QUANT_APPLICATION	Variable	Your application name (the workflows default to the repository name)
QUANT_BASE_URL	Variable	QuantGov only: https://dash.quantgov.cloud/api/v3 (or the host alone)

Tokens are secrets: GitHub masks them in logs and does not give them to workflows that run for pull requests from forks. Names and URLs are not sensitive; as variables they stay readable in the job log. For production, keep the secrets in a GitHub environment with protection rules.

Pin actions by commit SHA

A tag can move: @v4 follows each new 4.x release, and the owner of a repository can move any tag. A commit SHA cannot change. To control exactly what runs, pin the full SHA and keep the version in a comment:

- uses: quantcdn/quant-cloud-init-action@1bc52dca113ea1cb2f3d7dcb0edbc7859d76afaf # v4.0.1

Dependabot (package-ecosystem: github-actions in .github/dependabot.yml) opens pull requests that update the SHA and the comment together. To find the newest tag and its commit SHA: git ls-remote --tags --sort=-v:refname https://github.com/quantcdn/<action> 'v*.*.*' | head -2, then gh api repos/quantcdn/<action>/commits/<tag> --jq .sha.

A successful run does not mean the release is live

The actions ask the platform to deploy and finish when the request is accepted. They do not wait for the new containers to start or pass health checks. After a deploy, check the environment: qc env list --org <org> --app <app> shows running and desired task counts, qc env logs shows container output, and the dashboard Deployments tab shows each deployment’s status and error. To make a workflow wait, see the State Action.

Other CI systems

The qc CLI logs in through a browser (OAuth) and has no option for an unattended token login, so do not use it in CI jobs. In GitLab CI, Bitbucket Pipelines and other systems, call the platform API with curl and an API token, as the actions do:

API=https://dashboard.quantcdn.io/api/v3        # QuantGov: https://dash.quantgov.cloud/api/v3
AUTH="Authorization: Bearer $QUANT_API_KEY"     # from the CI system's masked secrets

# Registry login (short-lived credentials: endpoint, username, password)
CREDS=$(curl -fsS -H "$AUTH" "$API/organizations/$ORG/applications/ecr-login")
REGISTRY=$(printf '%s' "$CREDS" | jq -r .endpoint | sed -E 's#^https?://##')
printf '%s' "$CREDS" | jq -r .password |
  docker login "$REGISTRY" --username "$(printf '%s' "$CREDS" | jq -r .username)" --password-stdin

# Build and push <registry>/<organisation>/<application>:<service>-<suffix>
docker buildx build --platform linux/arm64 -t "$REGISTRY/$ORG/$APP:app-latest" --push .

# Redeploy the environment
curl -fsS -X PUT -H "$AUTH" -H "Content-Type: application/json" \
  -d '{"action": "redeploy"}' \
  "$API/organizations/$ORG/applications/$APP/environments/$ENV_NAME/state"

For static sites in other CI systems, use the quant CLI: see Using the Content CLI in CI/CD pipelines.

Common Use Cases

• Production deployment from main: the Init Action maps main to production. See the workflows in the Quant templates.
• Pull request environments: see Environment Action.
• Database sync from production to staging: see Sync Action.
• Scheduled backups with retention: see Backup Action.

Best Practices

1. Always start with the Init Action: it handles registry login and environment detection.
2. Use image_suffix_clean from init in image tags, after the compose service name.
3. Read the compose translation warnings printed by the Compose Action.
4. Protect production with GitHub environment protection rules.
5. Clean up preview environments when pull requests close.
6. Check each deploy as described above; a green run is not proof.

Next Steps

• Init Action Reference
• Quant templates for complete workflows