Stage 04b · Pipeline · 10 min
CI/CD Pipeline
Generate a GitHub Actions CI/CD pipeline — auto-deploy to staging, manual approval for prod
TALKING POINT · #29
- With the app built, tested, and security-scanned, we need a pipeline to automate delivery. We'll use GitHub Actions for this demo — but Bob supports other CI/CD tools too, including Jenkins, GitLab CI, Azure DevOps, and Tekton. The concepts are the same regardless of the tooling.
- The pipeline follows industry standard practice: CI runs automatically on every commit — build, test, scan, produce a Docker image. CD auto-promotes to staging so the team can validate. Only when someone explicitly approves does it touch production. This is the balance between developer speed and operational control.
- This separation maps directly to change management processes most enterprises already have — and in regulated industries, that human approval gate before production is often a compliance requirement.
Prompts
CI/CD Workflow Prompt
▼
Generate a GitHub Actions CI/CD workflow for this payment application.
Single cluster, two namespaces: bob-demo-staging and bob-demo-prod.
CI — runs on every PR and push to main:
1. Build with Maven (Java 17) from payment-app-java17/
2. Run JUnit tests — skip if commit message contains [skip checks]
3. Run OWASP dependency-check (fail on CVSS >= 7) — skip if commit message contains [skip checks]
4. Run Semgrep SAST scan — skip if commit message contains [skip checks]
IMPORTANT: Quality-gate jobs (test, owasp, semgrep) should NOT be in the 'needs'
array of docker-build-push. Only 'build' should be a dependency. Skippable jobs
in 'needs' cause all downstream jobs to skip regardless of 'if' conditions.
5. Build Docker image, tag with git SHA using:
${{ secrets.OPENSHIFT_REGISTRY }}/bob-demo-staging/payment-app:
6. Login to OpenShift internal registry using docker login with token:
echo "${{ secrets.OPENSHIFT_TOKEN }}" | docker login "${{ secrets.OPENSHIFT_REGISTRY }}" \
--username=unused --password-stdin
(Note: 'oc registry login' may fail on GitHub-hosted runners)
7. Push image to bob-demo-staging namespace
CD Staging — runs automatically after CI passes on push to main:
1. Use GitHub Secrets for sensitive data (OPENSHIFT_SERVER, OPENSHIFT_TOKEN, OPENSHIFT_REGISTRY)
and Variables for non-sensitive config (CLUSTER_DOMAIN). Variables are accessible in
all workflow contexts including environment.url; secrets are not.
2. Deploy to bob-demo-staging namespace using the image built in CI
3. Wait for deployment rollout, then explicitly wait for pod readiness:
oc wait --for=condition=ready pod -l app=payment-app -n bob-demo-staging --timeout=2m
4. Add 10-second grace period for service endpoint propagation
5. Retrieve route URL dynamically from OpenShift:
oc get route payment-app -n bob-demo-staging -o jsonpath='{.spec.host}'
6. Run smoke tests with complete payloads including all required fields:
cardNumber, expiryMonth, expiryYear, cvv, amount, currency
CD Production — runs after manual approval:
1. Promote image from staging to production namespace on the same cluster:
oc tag bob-demo-staging/payment-app: bob-demo-prod/payment-app:
2. Deploy the promoted image to bob-demo-prod namespace using rolling update strategy
3. Never rebuild the image — always promote the exact artifact validated in staging
Same OPENSHIFT_SERVER and OPENSHIFT_TOKEN used for both namespaces.
Credentials must never be hardcoded — use GitHub Secrets for all sensitive values.
Prerequisites:
- ServiceAccount must be defined in deployment manifest before Deployment references it
- Service account/token must have system:image-pusher role in target namespaces
- Deployment topology constraints should use 'ScheduleAnyway' for staging (not 'DoNotSchedule')
- Rolling update strategy should allow maxUnavailable: 1 for initial deployments
All in a single workflow file: .github/workflows/cicd.yml
PRESENTER NOTE · #30
Point out the three distinct sections — CI (build, test, scan, push to staging), CD Staging (automatic deploy), and CD Production (image promotion via oc tag, then deploy).Highlight the promotion pattern: production never rebuilds the image — it promotes the exact same artifact that passed staging. Same SHA, same bits. This is the industry standard and eliminates an entire class of "works in staging, breaks in prod" bugs.
TIP · #51
Remind the audience: we're using GitHub Actions for the demo, but Bob can generate equivalent pipelines for Jenkins, GitLab CI, Azure DevOps, Tekton, and others — same intelligence, different syntax.
TIP · #52
For the demo, use [skip checks] in your commit message to bypass JUnit, OWASP, and Semgrep — so the pipeline completes in under a minute. Example: git commit -m "demo: initial payment app [skip checks]". Remind the audience these gates would normally block a deploy if tests fail or a critical vulnerability is found.
TIP · #53
Cost: ~0.07 bobcoins.
Bob Produces
.github/workflows/cicd.yml — single pipeline: CI + auto-deploy to staging + manual approval for prod