CDX-301c · Module 3
Rollback Triggers & Multi-Stage Workflows
3 min read
Rollback triggers use Codex to analyze production incidents and recommend whether to roll back a deployment. When monitoring detects an anomaly (error rate spike, latency increase, health check failure), a CI workflow triggers Codex to analyze the most recent deployment diff, correlate it with the incident symptoms, and produce a rollback recommendation. The recommendation includes: likely root cause (which change in the diff could cause this symptom), confidence level, and suggested mitigation (rollback vs. hotfix).
Multi-stage workflows chain multiple Codex operations in a single pipeline. Stage 1: review the diff for correctness. Stage 2: generate tests for untested code paths. Stage 3: validate documentation updates. Stage 4: perform the deployment gate check. Each stage uses a different profile (model, timeout, rules) optimized for its task. Stages can run in parallel when independent or sequentially when one stage's output feeds the next. The workflow should short-circuit on failure — if Stage 1 finds a critical issue, skip Stage 2-4 to save time and cost.
name: Multi-Stage Codex Pipeline
on:
pull_request:
types: [opened, synchronize]
jobs:
stage-1-review:
runs-on: ubuntu-latest
outputs:
has-critical: ${{ steps.review.outputs.has-critical }}
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- run: npm install -g @openai/codex
- name: Critical Review
id: review
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
codex --profile review --approval full-auto \
"Check for critical issues only: security, data loss, breaking changes.
Output JSON: {critical: boolean, issues: string[]}" \
< <(git diff origin/${{ github.base_ref }}...HEAD) > review.json
echo "has-critical=$(jq -r '.critical' review.json)" >> "$GITHUB_OUTPUT"
stage-2-tests:
needs: stage-1-review
if: needs.stage-1-review.outputs.has-critical != 'true'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install -g @openai/codex
- name: Test Coverage Check
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: echo "Stage 2: checking test coverage..."
stage-3-gate:
needs: [stage-1-review, stage-2-tests]
if: needs.stage-1-review.outputs.has-critical != 'true'
runs-on: ubuntu-latest
steps:
- run: echo "Stage 3: deployment gate check..."
Do This
- Chain stages sequentially when output depends on previous stage
- Short-circuit the pipeline on critical findings — skip remaining stages
- Use different model profiles per stage — expensive models for critical checks only
- Log stage outputs as build artifacts for debugging failed pipelines
Avoid This
- Run all stages in parallel when they have dependencies — results will be inconsistent
- Run every stage regardless of previous failures — it wastes API budget
- Use the same model and profile for every stage — each has different requirements
- Build a monolithic single-stage pipeline — it is harder to debug and optimize