10 Expert Prompts for CI/CD Pipelines: GitHub Actions, GitLab CI, and ArgoCD

Introduction

Continuous Integration and Continuous Delivery (CI/CD) are the backbone of modern DevOps practices. They automate the building, testing, and deployment of code, enabling teams to release faster and with higher confidence. However, configuring CI/CD pipelines can be complex, especially when you need to orchestrate multiple tools, environments, and security checks.

Over the past few years, the DevOps community has developed a set of reusable, battle-tested prompts — or templates — for three major CI/CD platforms: GitHub Actions, GitLab CI, and ArgoCD. These prompts help you standardize workflows, enforce best practices, and reduce boilerplate code. In this article, I’ll share 10 expert-level prompts, organized by platform, with real-world examples and explanations.

By the end of this article, you’ll be able to copy, adapt, and combine these prompts to build robust CI/CD pipelines that handle everything from linting and testing to multi-environment deployments and rollbacks.

Prerequisites

Before diving into the prompts, ensure you have:
- Basic understanding of YAML syntax
- A GitHub, GitLab, or Kubernetes cluster (for ArgoCD) account
- Familiarity with Docker and containerization

1. GitHub Actions: Multi-Environment Deploy with Environment Guards

Task

Deploy a Node.js application to staging and production environments, with manual approval gates and secret injection.

Prompt

name: Multi-Environment Deploy

on:
  push:
    branches:
      - main
      - develop

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build.outputs.image }}
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        id: build
        run: |
          docker build -t myapp:${{ github.sha }} .
          echo "image=myapp:${{ github.sha }}" >> $GITHUB_OUTPUT
      - name: Push to registry
        run: |
          docker tag myapp:${{ github.sha }} myregistry.com/myapp:${{ github.sha }}
          docker push myregistry.com/myapp:${{ github.sha }}

  deploy-staging:
    needs: build
    environment:
      name: staging
      url: https://staging.myapp.com
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging
        run: |
          echo "Deploying ${{ needs.build.outputs.image }} to staging"
          # Your deployment script here

  deploy-production:
    needs: deploy-staging
    environment:
      name: production
      url: https://myapp.com
    runs-on: ubuntu-latest
    steps:
      - name: Wait for approval
        uses: trstringer/manual-approval@v1
        with:
          secret: ${{ secrets.APPROVAL_TOKEN }}
          approvers: admin,lead-dev
      - name: Deploy to production
        run: |
          echo "Deploying ${{ needs.build.outputs.image }} to production"

Example Result

When you push to main, the pipeline builds the Docker image, pushes it to the registry, deploys to staging automatically, then waits for a manual approval from admin or lead-dev before deploying to production. This prevents accidental releases and ensures only reviewed code reaches production.

2. GitHub Actions: Automated Dependency Scanning with Trivy

Task

Scan all pull requests for known vulnerabilities in dependencies using Trivy.

Prompt

name: Dependency Scan

on:
  pull_request:
    branches: [main]

jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
      - name: Upload Trivy results to GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

Example Result

On every pull request, Trivy scans the entire repository for vulnerable libraries. If any critical or high-severity vulnerabilities are found, they appear in the GitHub Security tab, and the pipeline can be configured to fail the PR. This prompt uses the official Trivy action from Aqua Security, which is widely adopted in the industry.

3. GitLab CI: Multi-Architecture Docker Build

Task

Build and push a Docker image for both linux/amd64 and linux/arm64 architectures using GitLab CI.

Prompt

build-multiarch:
  stage: build
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - |
      docker buildx create --use
      docker buildx build --platform linux/amd64,linux/arm64 \
        -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA \
        -t $CI_REGISTRY_IMAGE:latest \
        --push .
  only:
    - main

Example Result

When code is merged to main, GitLab CI spins up a Docker-in-Docker service, creates a Buildx builder, and compiles the same Dockerfile for both x86 and ARM architectures. The resulting multi-arch manifest is pushed to the GitLab Container Registry. This is essential for teams that support both cloud VMs (amd64) and edge devices (arm64).

4. GitLab CI: Database Migration with Rollback

Task

Run database migrations before deployment, and provide an automatic rollback if the migration fails.

Prompt

stages:
  - migrate
  - deploy
  - rollback

migrate:
  stage: migrate
  image: node:18-alpine
  script:
    - npm install
    - npx sequelize-cli db:migrate
  variables:
    DATABASE_URL: $STAGING_DATABASE_URL
  only:
    - main

rollback:
  stage: rollback
  image: node:18-alpine
  script:
    - npm install
    - npx sequelize-cli db:migrate:undo:all
  when: on_failure
  needs: ["migrate"]
  variables:
    DATABASE_URL: $STAGING_DATABASE_URL
  only:
    - main

Example Result

If the migrate job fails (e.g., due to a broken migration script), the rollback job automatically runs and undoes all migrations. This prevents the application from being deployed with an inconsistent database schema. The on_failure trigger is a GitLab CI feature that ensures rollback happens only when the migration fails.

5. ArgoCD: ApplicationSet with Multiple Clusters

Task

Deploy the same application to multiple Kubernetes clusters using ArgoCD ApplicationSet with a generator that reads cluster metadata.

Prompt

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp-clusters
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            environment: production
  template:
    metadata:
      name: '{{name}}-myapp'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/myapp-config
        targetRevision: HEAD
        path: overlays/{{name}}
      destination:
        server: '{{server}}'
        namespace: myapp
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Example Result

ArgoCD watches all clusters labeled environment: production. For each cluster, it creates an Application that syncs the kustomize overlay specific to that cluster. If you add a new production cluster with the correct label, ArgoCD automatically deploys the app to it — no manual configuration needed. This is a powerful pattern for multi-cluster GitOps.

6. ArgoCD: Sync Wave with Database Migration

Task

Run a database migration job before the main application deployment, and ensure the application only starts after the migration completes.

Prompt

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/myapp-manifests
    targetRevision: HEAD
    path: .
  destination:
    server: https://kubernetes.default.svc
    namespace: myapp
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
  sync:
    waves:
      - group: 1
        resources:
          - kind: Job
            name: db-migration
      - group: 2
        resources:
          - kind: Deployment
            name: myapp

Example Result

ArgoCD syncs resources in groups. First, it runs the db-migration Job. Only after that Job completes successfully does it deploy the main myapp Deployment. If the migration fails, ArgoCD stops and does not deploy the app, preventing schema mismatches. This approach uses ArgoCD’s sync waves feature, which is well-documented in the official ArgoCD documentation.

7. GitHub Actions + ArgoCD: Trigger GitOps Sync

Task

After a successful GitHub Actions build, trigger ArgoCD to sync the application in the cluster.

Prompt

name: Build and Trigger ArgoCD

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and push image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker push myregistry.com/myapp:${{ github.sha }}
      - name: Update manifest
        run: |
sed -i "s

|image: myapp:.*|image: myapp:${{ github.sha }}|" k8s/deployment.yaml
          git config user.name "CI"
          git config user.email "ci@example.com"
          git add k8s/deployment.yaml
          git commit -m "Update image to ${{ github.sha }}"
          git push

The last step updates the Kubernetes manifest in the GitOps repository. ArgoCD, which watches that repository, automatically syncs the change to the cluster.

Example Result

This creates a complete CI/CD pipeline: GitHub Actions builds the Docker image, updates the manifest file in a GitOps repo, and pushes the change. ArgoCD detects the drift and syncs the new image to the Kubernetes cluster. No direct access to the cluster is needed from the CI pipeline — a security best practice.

8. GitLab CI + ArgoCD: Multi-Environment Promotion with Gates

Task

Promote a build from staging to production using GitLab CI environment gates and ArgoCD ApplicationSets.

Prompt

stages:
  - build
  - deploy-staging
  - promote-to-production

build:
  stage: build
  script:
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA .
    - docker push myregistry.com/myapp:$CI_COMMIT_SHORT_SHA

deploy-staging:
  stage: deploy-staging
  script:
- sed -i "s

|image: myapp:.*|image: myapp:$CI_COMMIT_SHORT_SHA|" k8s/overlays/staging/deployment.yaml
    - git commit -m "Update staging image"
    - git push
  environment:
    name: staging

promote-to-production:
  stage: promote-to-production
  script:
- sed -i "s

|image: myapp:.*|image: myapp:$CI_COMMIT_SHORT_SHA|" k8s/overlays/production/deployment.yaml
    - git commit -m "Update production image"
    - git push
  environment:
    name: production
  when: manual
  only:
    - main

Example Result

On a push to main, GitLab CI builds the image and updates the staging overlay. After verifying the staging deployment, a developer manually triggers the promote-to-production job, which updates the production overlay. ArgoCD (configured with ApplicationSets pointing to these overlays) syncs both environments automatically. The manual gate prevents accidental production updates.

9. ArgoCD: Automated Rollback on Health Check Failure

Task

If a new deployment fails health checks, ArgoCD should automatically roll back to the previous stable version.

Prompt

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/myapp-manifests
    targetRevision: HEAD
    path: .
  destination:
    server: https://kubernetes.default.svc
    namespace: myapp
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - Validate=false
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas
  health:
    periodSeconds: 30
    failureThreshold: 3
    initialDelaySeconds: 60

Example Result

ArgoCD monitors the health of the deployed application. If the health check fails three times consecutively (e.g., the app crashes or liveness probe fails), ArgoCD automatically reverts the Deployment to the previous revision in the Git repository. This is a critical safety net for high-availability systems. Note: This requires proper health check endpoints in your application and correct liveness/readiness probes in the Deployment manifest.

10. GitHub Actions: Conditional Deployment Based on Commit Message

Task

Deploy to production only if the commit message contains [deploy].

Prompt

name: Conditional Deploy

on:
  push:
    branches: [main]

jobs:
  check-commit:
    runs-on: ubuntu-latest
    outputs:
      should-deploy: ${{ steps.check.outputs.should-deploy }}
    steps:
      - name: Check commit message
        id: check
        run: |
          if echo "${{ github.event.head_commit.message }}" | grep -q "\[deploy\]"; then
            echo "should-deploy=true" >> $GITHUB_OUTPUT
          else
            echo "should-deploy=false" >> $GITHUB_OUTPUT
          fi

  deploy:
    needs: check-commit
    if: needs.check-commit.outputs.should-deploy == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        run: |
          echo "Deploying because commit contains [deploy]"
          # Your deployment script

Example Result

When you push to main, the pipeline checks if the commit message contains [deploy]. If it does, the deploy job runs. If not, the workflow passes without deployment. This gives you fine-grained control over production releases while still running other checks (tests, linting) on every push.

Comparison Table

Best Practices

1. Use environment-specific secrets: Never hardcode credentials in your prompts. Use secrets in GitHub Actions, variables in GitLab CI, and SealedSecrets or External Secrets Operator with ArgoCD.
2. Lock dependencies: Pin action versions (e.g., actions/checkout@v4) and tool versions to prevent breaking changes.
3. Add notifications: Integrate Slack, Teams, or email alerts for pipeline failures using dedicated actions or webhooks.
4. Keep pipelines fast: Run parallel jobs for linting, unit tests, and security scans. Use caching for dependencies.
5. Document your pipelines: Add comments in YAML files and maintain a README for your CI/CD configuration.

Conclusion

These 10 prompts cover the most common CI/CD patterns used by DevOps teams today. By adopting them, you can standardize your pipelines across GitHub Actions, GitLab CI, and ArgoCD — reducing configuration errors and speeding up releases.

Remember that CI/CD is not just about automation; it’s about reliability and safety. Use environment gates, rollback mechanisms, and security scanning to protect your production systems. Start with one or two prompts from this list, adapt them to your stack, and gradually build a complete pipeline that fits your team’s workflow.

For further learning, explore the official documentation of each platform:
- GitHub Actions Documentation
- GitLab CI Documentation
- ArgoCD Documentation

Happy deploying!