Skip to content

github-workflows-dojo360-serverless-promotion

Promote serverless deployments across environments (dev→qa→cert→prod) using Dojo360 serverless-cd-promotion with deployment-path validation and approval gates

active
IDE:
claude
codex
vscode
Version:
1.0.0
Owner:pcorazao
github-actions
workflow
dojo360

Serverless CD Promotion Workflow Skill

Overview

The Serverless-CD Promotion workflow is a reusable GitHub Actions workflow that promotes (deploys) a serverless release candidate through multiple environments using a single workflow run.

It validates that the user-provided deployment-path matches the promotion-path defined in team metadata, then executes environment jobs in order. Between stages it can pause behind GitHub Environment protection rules (“approval gateway”), and it preserves the same ref for the entire promotion run.

Workflow Reference

Repository: dojo360/pipelines-workflows
Workflow: .github/workflows/serverless-cd-promotion.yml
Version: @beta (latest)
Documentation: https://github.com/dojo360/pipelines-workflows/tree/main/web/serverless-cd-promotion/index.md

Key Features

  • Multi-environment promotion: one workflow run promotes across multiple stages
  • Path validation: validates deployment-path against metadata promotion-path
  • Approval gates: uses GitHub Environments/protection rules between stages
  • Stable ref across stages: keeps the same git reference (ref) through all stages
  • Reuses Serverless-CD: runs Serverless-CD for each environment stage
  • E2E testing per stage: optional E2E workflow execution after selected stages
  • CI output integration: can pass artifact-name from CI job outputs
  • EFIX support: supports user-defined stages for emergency fix flows

Prerequisites

  1. Team metadata: Product must be onboarded to Dojo360 Metadata API (or equivalent local metadata) and include a valid promotion-path.
  2. GitHub Environments: Create environments matching your deployment stages (e.g., dev, qa, cert, prod) and configure protection rules/approvers as needed.
  3. OIDC setup (cloud dependent):
    • AWS (e.g., awsOptum, awsChc20): GitHub OIDC trust + IAM role for the workflow runner
    • Azure (e.g., azureOptum): OIDC app registration/service principal configuration
  4. Artifact access: Ensure the workflow has access to the artifact repository (Artifactory / GitHub / etc.) where your serverless build artifact lives.

Requirements

  • Terraform ~> 1.9.x
  • AWS ~> 5.xx (for AWS operations)
  • AzureRM ~> 3.xx (for Azure operations)
  • GCP ~> 6.xx (for GCP operations)

Required Inputs

InputTypeDescription
aide-idstringAIDE ID used to fetch team metadata
artifact-namestringName of the artifact to deploy
cloud-typestringCloud provider for metadata/deployment (see Supported Cloud Types in Dojo360 docs)
deployment-pathstringPromotion path to execute (e.g., dev-qa-cert-prod)
domainstringDomain used for metadata lookup
environmentstringInitial environment value used to define approvals (required in Dojo360 usage examples)
team-namestringTeam name used for metadata lookup

Common Optional Inputs

InputTypeDefaultDescription
artifact-repo-pathstring''Path within the artifact repository/repo where artifacts are stored
artifact-repositorystring''Repository/registry where artifacts are stored
e2e-tests-enabled-stagesstring''Comma-separated stages where E2E should run (e.g., qa,cert)
e2e-workflow-filestring''Workflow file to run for E2E
e2e-workflow-inputsstring (JSON)''JSON string of inputs for the E2E workflow
jfrog-project-keystring''JFrog project key (SaaS Artifactory)
prm-base-urlstringhttps://prm.optum.comPRM base URL
refstring(auto)Branch/tag/SHA to checkout; promotion keeps the same ref across stages
remote-state-file-namestring''Remote Terraform state file name
remote-state-folder-namestring''Remote Terraform state folder name
runner-labelsstring''Comma-separated runner labels
terraform-directorystringtfTerraform directory relative to repo
terraform-prm-secretsstring''Comma-separated PRM secret names mapped to tfvars
terraform-provider-network-mirrorstringDojo360 defaultTerraform provider mirror/proxy URL
terraform-vars-filesstring''Comma-separated list of .tfvars files
terraform-vars-valuesstring (JSON)''JSON string of Terraform vars
terraform-versionstring1.9.2Terraform version
terraform-volcan-secretsstring''Comma-separated Volcan secret names mapped to tfvars
volcan-base-urlstringvolcan-cloud.optum.comVolcan base URL

Required Workflow Permissions

permissions:
  id-token: write
  contents: write
  actions: read
  pull-requests: write
  security-events: write
  checks: write
  issues: read

Required Secrets

  • GH_TOKEN: GitHub token for workflow operations
  • REPO_USERNAME: Artifact repository username (required when your artifact source requires auth)
  • REPO_PASSWORD: Artifact repository password/token (required when your artifact source requires auth)

Templates

See the ready-to-copy examples in .github/skills/github-workflows-dojo360-serverless-promotion/templates/:

  • basic-serverless-promotion.yml
  • promotion-with-e2e-testing.yml
  • promotion-with-prm-secrets.yml
  • ci-cd-integrated-promotion.yml

Notes / Gotchas

  • Promotion workflows are intended for default branch and tag-triggered pipelines.
  • deployment-path must align with your metadata promotion-path (otherwise the workflow exits early).
  • GitHub Environment protection rules are what create the approval “stop points” between stages.

Related Assets