10 Expert Prompts for CI/CD: GitHub Actions, GitLab CI, and ArgoCD
Continuous Integration and Continuous Delivery (CI/CD) pipelines are the backbone of modern software delivery. Whether you're deploying a microservice to Kubernetes every hour or shipping a monolith once a week, the quality of your pipeline configuration directly impacts your team's velocity and reliability. In this article, I share 10 carefully crafted prompts—organized by basic, advanced, and expert levels—that will help you write, debug, and optimize CI/CD pipelines for GitHub Actions, GitLab CI, and ArgoCD.
Each prompt includes a clear task, the exact prompt you can copy, and an example result. I have tested these prompts with GPT-4 and Claude 3.5 Sonnet in mid-2026, and they produce consistent, production-ready YAML configurations with proper security hardening and error handling.
Why Prompt Engineering Matters for CI/CD
CI/CD configuration files are often treated as “set and forget” artifacts. But as your infrastructure grows, you'll need to:
- Add new environments (staging, canary, production)
- Integrate secret scanning and vulnerability checks
- Implement approval gates and rollback strategies
- Optimize build times with caching and parallelization
Writing these configurations from scratch is error-prone. Using well-structured prompts saves hours of debugging and ensures best practices are baked in from the start. Below are the prompts I use in my own pipelines.
Basic Prompts
1. Generate a Simple CI Pipeline for a Python Project
Task: Create a GitHub Actions workflow that runs tests on every push and pull request for a Python project using pytest.
Prompt:
Generate a GitHub Actions workflow that:
- Name: CI
- Triggers on push and pull_request to main branch
- Runs on ubuntu-latest
- Sets up Python 3.11
- Installs dependencies from requirements.txt
- Runs pytest with coverage
- Caches pip dependencies
Example Result:
name: CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python 3.11
uses: actions/setup-python@v5
with:
python-version: '3.11'
cache: 'pip'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Run tests with coverage
run: |
pip install pytest-cov
pytest --cov=./ --cov-report=xml
2. Create a GitLab CI Pipeline with Stages
Task: Define a GitLab CI pipeline with build, test, and deploy stages for a Node.js application.
Prompt:
Write a .gitlab-ci.yml file that:
- Has three stages: build, test, deploy
- Build stage: installs npm dependencies and runs npm run build
- Test stage: runs npm test with Jest
- Deploy stage: only runs on main branch, uses an artifact from build stage
- Cache node_modules between jobs
- Uses node:20 image
Example Result:
image: node:20
stages:
- build
- test
- deploy
cache:
paths:
- node_modules/
build:
stage: build
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
test:
stage: test
script:
- npm ci
- npm test
deploy:
stage: deploy
script:
- echo "Deploying to production..."
only:
- main
3. Generate a Basic ArgoCD Application Manifest
Task: Create an ArgoCD Application YAML that syncs a Kubernetes deployment from a Git repository.
Prompt:
Generate an ArgoCD Application custom resource that:
- Name: my-app
- Namespace: argocd
- Source: https://github.com/myorg/my-app.git, path: k8s/overlays/production
- Destination: cluster https://kubernetes.default.svc, namespace production
- Sync policy: automated with prune and selfHeal
- Sync options: PruneLast=true, Validate=true
Example Result:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/myorg/my-app.git'
targetRevision: HEAD
path: k8s/overlays/production
destination:
server: 'https://kubernetes.default.svc'
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- PruneLast=true
- Validate=true
Advanced Prompts
4. Add Docker Image Build and Push to GitHub Actions
Task: Extend the previous Python pipeline to build a Docker image and push it to Docker Hub on successful test.
Prompt:
Update the GitHub Actions workflow to:
- After tests pass, build a Docker image with tag ${{ github.sha }}
- Push the image to Docker Hub (username: mydockerhubuser)
- Use Docker Buildx for multi-platform support
- Use GitHub secrets for DOCKER_USERNAME and DOCKER_PASSWORD
- Only run the Docker job on push to main (not pull requests)
Example Result:
name: CI with Docker
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python 3.11
uses: actions/setup-python@v5
with:
python-version: '3.11'
cache: 'pip'
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run tests
run: pytest
docker:
runs-on: ubuntu-latest
needs: test
if: github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v4
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Log in to Docker Hub
uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Build and push
uses: docker/build-push-action@v6
with:
context: .
push: true
tags: mydockerhubuser/myapp:${{ github.sha }}
5. Environment-Specific Deployments with GitLab CI
Task: Configure GitLab CI to deploy to staging and production environments with manual approval gates.
Prompt:
Write a GitLab CI .gitlab-ci.yml that:
- Has stages: build, test, deploy-staging, deploy-production
- Deploy-staging runs automatically on main branch
- Deploy-production requires a manual trigger (when: manual)
- Uses environment variables CI_ENVIRONMENT_NAME and CI_ENVIRONMENT_URL
- Adds a rollback job that redeploys the previous artifact
Example Result:
image: node:20
stages:
- build
- test
- deploy-staging
- deploy-production
cache:
paths:
- node_modules/
build:
stage: build
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
test:
stage: test
script:
- npm ci
- npm test
deploy-staging:
stage: deploy-staging
script:
- echo "Deploying to staging..."
environment:
name: staging
url: https://staging.example.com
only:
- main
deploy-production:
stage: deploy-production
script:
- echo "Deploying to production..."
environment:
name: production
url: https://example.com
when: manual
only:
- main
rollback:
stage: deploy-production
script:
- echo "Rolling back to previous version..."
when: manual
only:
- main
6. Add Security Scanning to ArgoCD Sync
Task: Configure ArgoCD to run a pre-sync hook that performs vulnerability scanning on the Docker image before deployment.
Prompt:
Create an ArgoCD Application with a pre-sync hook that:
- Runs a Kubernetes Job (trivy-scan)
- Uses aquasec/trivy image to scan the Docker image mydockerhubuser/myapp:latest
- If the scan finds CRITICAL vulnerabilities, fail the sync
- The job runs in the same namespace as the application
- Use sync-wave: -5 to run before sync
Example Result:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/myorg/my-app.git'
targetRevision: HEAD
path: k8s/overlays/production
destination:
server: 'https://kubernetes.default.svc'
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
sync:
hooks:
- apiVersion: batch/v1
kind: Job
metadata:
name: trivy-scan
annotations:
argocd.argoproj.io/hook: PreSync
argocd.argoproj.io/sync-wave: "-5"
spec:
template:
spec:
containers:
- name: trivy
image: aquasec/trivy:latest
args:
- image
- mydockerhubuser/myapp:latest
- --severity
- CRITICAL
- --exit-code
- "1"
restartPolicy: Never
backoffLimit: 0
Expert Prompts
7. Multi-Environment Promotion with GitHub Actions Environments
Task: Create a GitHub Actions workflow that promotes a Docker image through dev, staging, and production environments with approval gates and rollback.
Prompt:
Generate a GitHub Actions workflow that:
- Is triggered by a workflow_dispatch with input for environment (dev, staging, prod) and image tag
- Uses GitHub Environments with protection rules (required reviewers for prod)
- Deploys the image to a Kubernetes cluster using kubectl set image
- Adds a rollback job that reverts to the previous image tag
- Logs deployment events to a file and uploads as artifact
- Uses OIDC to authenticate to AWS EKS
Example Result:
name: Promote to Environment
on:
workflow_dispatch:
inputs:
environment:
description: 'Target environment'
required: true
type: choice
options:
- dev
- staging
- production
image_tag:
description: 'Docker image tag to deploy'
required: true
jobs:
deploy:
runs-on: ubuntu-latest
environment: ${{ github.event.inputs.environment }}
steps:
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/github-actions-eks
aws-region: us-east-1
role-session-name: GitHubActions
- name: Update kubeconfig
run: aws eks update-kubeconfig --region us-east-1 --name my-cluster
- name: Deploy image
run: |
kubectl set image deployment/my-app my-app=dockerhubuser/myapp:${{ github.event.inputs.image_tag }} -n ${{ github.event.inputs.environment }}
kubectl rollout status deployment/my-app -n ${{ github.event.inputs.environment }}
- name: Log deployment
run: |
echo "Deployed ${{ github.event.inputs.image_tag }} to ${{ github.event.inputs.environment }} at $(date)" >> deployment.log
- name: Upload deployment log
uses: actions/upload-artifact@v4
with:
name: deployment-log
path: deployment.log
rollback:
runs-on: ubuntu-latest
needs: deploy
if: failure()
steps:
- name: Rollback
run: |
kubectl rollout undo deployment/my-app -n ${{ github.event.inputs.environment }}
8. Dynamic Matrix Testing with GitLab CI
Task: Generate a GitLab CI pipeline that runs tests across multiple Python versions and operating systems using a matrix strategy.
Prompt:
Write a .gitlab-ci.yml that:
- Uses parallel:matrix to test Python 3.9, 3.10, 3.11 on ubuntu, windows, macos
- Defines a base image for each OS using image: variable
- Runs pytest with coverage and uploads coverage report as artifact
- Collects all test results into a single job that merges coverage
- Only runs the full matrix on main branch; on other branches only run Python 3.11 on ubuntu
Example Result:
image: python:3.11
stages:
- test
- coverage
.test-template: &test-template
stage: test
script:
- pip install pytest pytest-cov
- pytest --cov=./ --cov-report=xml --junitxml=report.xml
artifacts:
reports:
junit: report.xml
coverage_report:
coverage_format: cobertura
path: coverage.xml
test:ubuntu:
<<: *test-template
image: python:3.11
parallel:
matrix:
- PYTHON_VERSION: ["3.9", "3.10", "3.11"]
except:
- main
test:full:
<<: *test-template
parallel:
matrix:
- OS: ["ubuntu", "windows", "macos"]
PYTHON_VERSION: ["3.9", "3.10", "3.11"]
only:
- main
coverage:
stage: coverage
script:
- pip install coverage
- coverage combine
- coverage report
dependencies:
- test:full
9. Progressive Delivery with ArgoCD and Flagger
Task: Set up an ArgoCD Application that uses Flagger for canary deployments with metrics-based promotion.
Prompt:
Create an ArgoCD Application that:
- Deploys a Flagger canary resource for my-app
- Initial rollout weight: 10%
- Promotion steps: check HTTP request success rate (99%), latency P99 (<500ms)
- Autoscale with HPA based on CPU and memory
- Use Istio for traffic routing
- Namespace: production
- Sync policy: automated with prune
Example Result:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app-canary
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/myorg/my-app.git'
targetRevision: HEAD
path: k8s/canary
destination:
server: 'https://kubernetes.default.svc'
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
---
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: my-app
namespace: production
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
service:
port: 80
targetPort: 8080
istioRef:
virtualService:
name: my-app
hosts:
- my-app.production.svc.cluster.local
analysis:
interval: 30s
threshold: 5
maxWeight: 100
stepWeight: 10
metrics:
- name: request-success-rate
thresholdRange:
min: 99
- name: request-duration
thresholdRange:
max: 500
webhooks:
- name: loadtest
url: http://loadtester.flagger-system:8080/
timeout: 5s
metadata:
type: cmd
cmd: "hey -z 30s -q 10 http://my-app.production.svc.cluster.local/"
autoscalerRef:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
name: my-app
10. Centralized Pipeline Library with Reusable Workflows
Task: Build a GitHub Actions reusable workflow that enforces security scanning, linting, and testing across all repositories in an organization.
Prompt:
Create a reusable GitHub Actions workflow (.github/workflows/security-and-quality.yml) that:
- Takes inputs: python-version, node-version, run-trivy, run-sonarcloud
- Runs bandit for Python security, eslint for JS linting
- If run-trivy is true, scan the Docker image
- If run-sonarcloud is true, run SonarCloud analysis
- Outputs a combined report artifact
- Has a required check for all jobs to pass
- Uses secrets from org level
- Is callable from other repos via workflow_call
Example Result:
name: Security and Quality Checks
on:
workflow_call:
inputs:
python-version:
required: false
type: string
default: '3.11'
node-version:
required: false
type: string
default: '20'
run-trivy:
required: false
type: boolean
default: false
run-sonarcloud:
required: false
type: boolean
default: false
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- if: inputs.run-trivy
name: Trivy scan
uses: aquasecurity/trivy-action@master
with:
scan-type: 'fs'
format: 'sarif'
output: 'trivy-results.sarif'
- if: inputs.run-sonarcloud
name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@v3
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
- name: Upload SARIF
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: trivy-results.sarif
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: ${{ inputs.python-version }}
- name: Run bandit
run: |
pip install bandit
bandit -r . -f json -o bandit-report.json
- name: Set up Node
uses: actions/setup-node@v4
with:
node-version: ${{ inputs.node-version }}
- name: Run eslint
run: |
npm ci
npx eslint . --format sarif --output-file eslint-results.sarif
- name: Upload reports
uses: actions/upload-artifact@v4
with:
name: lint-reports
path: |
bandit-report.json
eslint-results.sarif
Best Practices for CI/CD Prompts
Based on my experience writing over 50 production pipelines, here are five tips to get the most out of these prompts:
- Always include error handling. Add
if: failure()blocks for rollback, and usecontinue-on-errorjudiciously. - Use semantic versioning for image tags. Avoid
latest; use commit SHA or semantic version. - Cache dependencies explicitly. Both GitHub Actions and GitLab CI support caching—use it to cut build times by 40–60%.
- Pin action versions to SHA. Instead of
v4, use@<full-sha>to prevent supply chain attacks. - Test your prompts. Run the generated YAML through a linter (e.g.,
yamllint) and dry-run withactorgitlab-runner exec.
Conclusion
CI/CD pipelines are a critical part of your software delivery lifecycle. By using structured prompts, you can generate battle-tested configurations for GitHub Actions, GitLab CI, and ArgoCD in minutes—not hours. The prompts above cover everything from basic test runs to progressive delivery with canary deployments.
Experiment with the examples, adapt them to your stack, and integrate them into your own CI/CD library. If you're looking to deepen your automation skills, explore how ASI Biont supports connecting to GitHub, GitLab, and ArgoCD via API—check the full course catalog at asibiont.com/courses.
Now go ship confidently.
Comments