💻 Coding
DevOps Engineer Prompt: CI/CD Pipeline Review and Fix Plan
Review a pasted CI/CD pipeline for secret exposure, risky triggers, unpinned actions, slow steps, and missing gates, then get a patched config and rollout plan.
0Reviews
Prompt
Act as a senior DevOps engineer who reviews CI/CD pipeline configs for security, reliability, and speed, and returns a minimal patch plus a rollout plan that will not break the team's next deploy. Inputs: - Pipeline file or files (GitHub Actions, GitLab CI, or similar), with secrets removed: [PipelineConfig] - CI platform and runner type (hosted or self-hosted): [Platform] - What the pipeline must do (build, test, scan, deploy targets): [PipelineGoal] - Deploy targets and how credentials are provided today: [DeployAuth] - Branch and release rules (protected branches, environments, approvals): [BranchRules] - Pain points (slow runs, flaky tests, failed deploys): [PainPoints] - What I cannot change this sprint: [Constraints] Generate: 1. Pipeline summary: triggers, jobs, order, and where secrets and credentials are used. 2. Findings table: severity (critical, high, medium, low), file and line or job, issue, risk in one sentence, and fix. Check for untrusted code running with secrets, overly broad token permissions, long-lived cloud keys, third-party actions or images not pinned to a commit or digest, missing concurrency control, no caching, deploys without an environment gate, and secrets printed to logs. 3. Constraint conflicts: any fix blocked by Constraints, with a safer interim step. 4. Patched config: only the changed parts, valid for Platform, with a comment on each change. 5. Speed fixes for PainPoints: caching, job splits, or test sharding, with what to measure before and after. 6. Rollout plan: test the change on a branch, what to watch in the first runs, and how to roll back. 7. Follow-ups: work outside the pipeline file, such as cloud role setup or branch protection settings. Rules: - Never ask for or print real secrets, tokens, or account IDs; use placeholders. - Do not invent action names, versions, or platform features; if unsure a feature exists on Platform, say so. - Keep the patch minimal; style changes go in the table only.
Instructions
Remove real secrets, account IDs, and internal hostnames before pasting your pipeline file. Works on ChatGPT, Claude, and Gemini. Test the patched config on a branch first, check any action or feature you do not recognize in your CI platform's docs, and keep your current file until the new one deploys cleanly. Never paste tokens, passwords, private keys, kubeconfigs, or .env values; use placeholders and keep real secrets in your CI platform's secret store.
Generated Output
This image was generated using the prompt above.
Examples
Example Input
PipelineConfig:
name: ci
on: [push, pull_request_target]
jobs:
build-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
- uses: some-org/setup-tool@master
- run: npm install
- run: npm test
- run: echo "key=${{ secrets.AWS_SECRET_ACCESS_KEY }}"
- run: aws s3 sync ./dist s3://my-app-prod --delete
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
Platform: GitHub Actions, hosted runners
PipelineGoal: test every pull request, deploy the static site to S3 only from main
DeployAuth: long-lived AWS access keys stored as repo secrets
BranchRules: main is protected, one approval needed
PainPoints: runs take about 9 minutes, mostly npm install
Constraints: cannot change the S3 bucket or the build command this sprintExample Output
1. PIPELINE SUMMARY
One job runs on every push and on pull_request_target. It checks out the PR head commit, installs, tests, prints a secret, and syncs to the production bucket using long-lived AWS keys, on every trigger including forks.
2. FINDINGS
| Sev | Where | Issue | Risk | Fix |
| critical | on: pull_request_target + checkout of PR head | untrusted PR code runs with repo secrets | a fork PR can steal AWS keys | use pull_request for tests; no secrets in PR jobs |
| critical | run: echo key=... | secret printed to logs | masking can fail on transformed values | delete the step |
| critical | deploy step | deploys on every trigger | any PR can overwrite prod | separate deploy job, main only, environment gate |
| high | DeployAuth | long-lived AWS keys | leaked keys work until rotated | OIDC with a short-lived role |
| high | some-org/setup-tool@master | unpinned third-party action | upstream change runs in your pipeline | pin to a full commit SHA |
| medium | no permissions block | default token scope may be broad | more damage if compromised | permissions: contents: read |
| medium | npm install | no lockfile install, no cache | slow and not reproducible | npm ci with setup-node cache |
| low | no concurrency | overlapping deploys | race on the bucket | concurrency group for deploy |
3. CONSTRAINT CONFLICTS
Bucket and build command stay the same; the patch keeps aws s3 sync ./dist s3://my-app-prod --delete and npm test unchanged. If OIDC role setup cannot happen this sprint, keep the keys only in a production environment secret and rotate them now.
4. PATCHED CONFIG
on:
pull_request: # tests for PRs, no secrets
push:
branches: [main]
permissions:
contents: read # least privilege by default
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<full-commit-sha> # pinned
- uses: actions/setup-node@<full-commit-sha>
with: { node-version-file: .nvmrc, cache: npm }
- run: npm ci
- run: npm test
deploy:
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
needs: test
runs-on: ubuntu-latest
environment: production # approval gate
concurrency: { group: deploy-prod, cancel-in-progress: false }
permissions: { contents: read, id-token: write } # OIDC
steps:
- uses: actions/checkout@<full-commit-sha>
- uses: aws-actions/configure-aws-credentials@<full-commit-sha>
with:
role-to-assume: arn:aws:iam::<ACCOUNT_ID>:role/<DEPLOY_ROLE>
aws-region: <REGION>
- run: npm ci && npm run build # replace with your existing build command
- run: aws s3 sync ./dist s3://my-app-prod --delete
some-org/setup-tool removed; add it back pinned to a SHA if a step needs it.
5. SPEED
npm ci with the npm cache should cut most of the install time. Record the current run time, then compare the next five runs.
6. ROLLOUT
Open a PR with the new file; confirm the test job runs and no deploy job appears. Merge, approve the production environment, and watch the first deploy. Roll back by reverting the commit.
7. FOLLOW-UPS
Create the IAM role with a trust policy limited to this repo and main. Add required reviewers to the production environment. Rotate, then delete the old access keys.