GCP Cloud Build

Register your GCP Cloud Build deployments with Firetiger so that deploy monitoring can track changes, correlate them with observability data, and catch deployment-specific issues.

Prerequisites

A Firetiger account with the GitHub Connection installed
A GCP project with Cloud Build enabled
Deploy credentials from the Deployments page — copy the Authorization header value (a Basic token encoding your username and password)

Store the credential in Secret Manager

Create a secret containing the authorization header value from the Deployments page:

echo -n "Basic WTNKb..." | gcloud secrets create firetiger-deploy-token \
  --data-file=- \
  --replication-policy=automatic

Grant your Cloud Build service account access to the secret. Replace <BUILD_SA> with the service account your builds run as — this is the legacy Cloud Build service account, the Compute Engine default SA, or a user-specified service account depending on your project’s configuration:

gcloud secrets add-iam-policy-binding firetiger-deploy-token \
  --member="serviceAccount:<BUILD_SA>" \
  --role="roles/secretmanager.secretAccessor"

Add a registration step to `cloudbuild.yaml`

Add the following step to the end of your cloudbuild.yaml, after your deploy step:

steps:
  # ... your existing build and deploy steps ...

  - id: register-firetiger-deployment
    name: curlimages/curl
    entrypoint: sh
    args:
      - -c
      - |
        curl -sf -X POST https://api.cloud.firetiger.com/deployments \
          -H "Authorization: $$FT_DEPLOY_TOKEN" \
          -H "Content-Type: application/json" \
          -d '{
            "repository":   "$_REPOSITORY",
            "environment":  "$_ENVIRONMENT",
            "sha":          "$COMMIT_SHA"
          }'
    secretEnv:
      - FT_DEPLOY_TOKEN

availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/firetiger-deploy-token/versions/latest
      env: FT_DEPLOY_TOKEN

substitutions:
  _REPOSITORY: "your-org/your-repo"   # owner/repo format
  _ENVIRONMENT: "production"

Failed deploys: Because the registration step runs after your deploy step, Cloud Build will skip it if the deploy fails. This means only successful deployments are registered with Firetiger.

Variable escaping: $$FT_DEPLOY_TOKEN uses a double $$ because it references a secretEnv variable — Cloud Build requires the double-dollar prefix to distinguish secret environment variables from built-in substitutions like $COMMIT_SHA. This is a common gotcha.

Repository format: The repository field requires owner/repo format (e.g. acme-corp/api-server). Cloud Build’s built-in $REPO_NAME only provides the repo name without the owner, so the example uses a user-defined _REPOSITORY substitution instead.

Verify

Trigger a build and check the register-firetiger-deployment step in Cloud Build logs — you should see a 200 response with a JSON body like {"name": "deployments/..."}.
Confirm the deployment appears on the Deployments page in the Firetiger UI.

Next steps

Tag a PR for monitoring so Firetiger develops a targeted plan for your changes
Review the deploy monitoring guide for the full workflow: PR tagging, monitoring plans, and the check schedule