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

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

Introduction

Continuous Integration and Continuous Delivery (CI/CD) pipelines are the backbone of modern software delivery. Yet many teams struggle to write effective pipeline configuration, debug failures, or optimize build times. The right prompts — used with AI assistants like ChatGPT or Copilot — can save hours of trial and error. This article provides 10 ready-to-use prompts for the three most popular CI/CD platforms: GitHub Actions, GitLab CI, and ArgoCD. Each prompt is designed to solve a specific real-world problem, complete with an example output and explanation. Whether you are a DevOps engineer or a developer setting up your first pipeline, these prompts will accelerate your workflow.

1. GitHub Actions: Multi-Architecture Docker Build

Prompt: "Create a GitHub Actions workflow that builds and pushes a Docker image for both linux/amd64 and linux/arm64 architectures, using Docker Buildx and caching to speed up subsequent builds. Include a step to log in to Docker Hub using secrets."

Why this prompt matters: Many developers need to support both x86 and ARM processors (Apple Silicon, AWS Graviton). Manually setting up multi-arch builds is error-prone. This prompt automates it.

Example output (YAML snippet):

name: Multi-Arch Docker Build
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    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@v5
        with:
          push: true
          tags: myuser/myapp:latest
          platforms: linux/amd64,linux/arm64
          cache-from: type=gha
          cache-to: type=gha,mode=max

Usage example: Save this as .github/workflows/docker-multiarch.yml. The first run may take longer (no cache), but subsequent runs will use GitHub Actions cache for faster builds.

2. GitLab CI: Parallel Test Execution with JUnit Reports

Prompt: "Generate a .gitlab-ci.yml file that runs unit tests in parallel across three jobs (test-frontend, test-backend, test-integration), each producing a JUnit report. The pipeline should fail only if critical tests fail, but allow non-critical failures. Use artifacts to pass reports to a final 'report' job."

Why this prompt matters: Slow test suites block deployment. Parallel execution and reporting are essential for fast feedback.

Example output (YAML snippet):

stages:
  - test
  - report

test-frontend:
  stage: test
  script: npm test -- --report junit
  artifacts:
    reports:
      junit: frontend/test-results.xml
    when: always

test-backend:
  stage: test
  script: pytest --junitxml=backend/test-results.xml
  artifacts:
    reports:
      junit: backend/test-results.xml
    when: always

test-integration:
  stage: test
  script: ./run-integration-tests --junit integration/results.xml
  artifacts:
    reports:
      junit: integration/results.xml
    when: always

report:
  stage: report
  script: echo "All tests completed. See merge request for details."
  dependencies: []

Usage example: This configuration allows the frontend job to fail without blocking backend tests (if you set allow_failure: true). The report job aggregates results in GitLab's merge request UI.

3. ArgoCD: Sync Policy for Canary Deployments

Prompt: "Write an ArgoCD Application manifest that deploys a microservice with a canary sync policy: 10% traffic for 5 minutes, then 50% for 10 minutes, then 100%. Use the Argo Rollouts extension and set auto-sync with prune."

Why this prompt matters: Canary deployments reduce risk. ArgoCD with Rollouts provides declarative progressive delivery.

Example output (YAML snippet):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-canary
spec:
  destination:
    namespace: production
    server: https://kubernetes.default.svc
  project: default
  source:
    repoURL: https://github.com/myorg/myapp.git
    path: k8s
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  rollouts:
    - name: myapp-rollout
      strategy:
        canary:
          steps:
            - setWeight: 10
            - pause: {duration: 5m}
            - setWeight: 50
            - pause: {duration: 10m}
            - setWeight: 100

Usage example: Apply this manifest to your cluster. When you update the image version in the Git repo, ArgoCD will sync and perform the canary steps automatically.

4. GitHub Actions: Automated Dependency Updates with Dependabot

Prompt: "Create a GitHub Actions workflow that runs every Monday at 9 AM, checks for outdated npm dependencies using npm outdated, and creates an issue with a summary of outdated packages. If dependencies are critical security updates, the workflow should automatically create a pull request."

Why this prompt matters: Dependency drift is a major security risk. Automating checks reduces manual overhead.

Example output (YAML snippet):

name: Dependency Check
on:
  schedule:
    - cron: '0 9 * * 1'
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Check outdated
        id: outdated
        run: |
          npm outdated --json > outdated.json
          echo "count=$(jq length outdated.json)" >> $GITHUB_OUTPUT
      - name: Create issue if outdated
        if: steps.outdated.outputs.count > 0
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const data = JSON.parse(fs.readFileSync('outdated.json','utf8'));
            let body = '### Outdated packages\n';
            for (const [pkg, info] of Object.entries(data)) {
              body += `- **${pkg}**: ${info.current} -> ${info.wanted}\n`;
            }
            github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: 'Outdated dependencies detected',
              body: body
            });

Usage example: After the first Monday run, an issue appears in your repo listing outdated packages. You can extend the script to auto-PR for security updates by parsing npm audit.

5. GitLab CI: Multi-Environment Deployment with Manual Approval

Prompt: "Create a GitLab CI pipeline that deploys a web application to three environments (staging, preprod, production). Staging deploys automatically on every commit to develop. Preprod requires a manual trigger from a tag. Production requires a manual approval from a specific user group."

Why this prompt matters: Controlled deployments are critical for compliance and stability. Manual gates prevent accidental releases.

Example output (YAML snippet):

stages:
  - build
  - deploy-staging
  - deploy-preprod
  - deploy-prod

build:
  stage: build
  script: docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
  only:
    - develop
    - tags

deploy-staging:
  stage: deploy-staging
  script: ./deploy.sh staging
  only:
    - develop

deploy-preprod:
  stage: deploy-preprod
  script: ./deploy.sh preprod
  only:
    - tags
  when: manual

deploy-prod:
  stage: deploy-prod
  script: ./deploy.sh production
  only:
    - tags
  when: manual
  needs: [deploy-preprod]
  environment:
    name: production
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v[0-9]+\.[0-9]+\.[0-9]+$/'

Usage example: After pushing a tag like v1.2.3, the preprod job appears — a developer clicks "play" to deploy to preprod. Then the production job waits for an approved member of the production-deployers group to manually trigger it.

6. ArgoCD: ApplicationSet with Multiple Clusters

Prompt: "Write an ArgoCD ApplicationSet that deploys the same application to two clusters (us-east-1 and eu-west-1) using a generator that reads cluster names from a JSON file. Each deployment should have a different replica count defined per cluster."

Why this prompt matters: Managing multi-cluster deployments manually is tedious. ApplicationSet automates this.

Example output (YAML snippet):

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

Usage example: Create a file clusters.json with labels: {"name": "us-east-1", "server": "https://us-east.example.com"} and {"name": "eu-west-1", "server": "https://eu-west.example.com"}. The ApplicationSet generates one App per cluster.

7. GitHub Actions: Conditional Deploy Based on Branch Name

Prompt: "Write a GitHub Actions workflow that builds a React app and deploys it to Firebase Hosting. If the branch is main, deploy to production. If the branch is staging, deploy to a staging site. For any other branch, deploy to a preview channel with a unique URL."

Why this prompt matters: Preview deployments are essential for frontend teams to review changes before merging.

Example output (YAML snippet):

name: Firebase Deploy
on:
  push:
    branches:
      - '*'
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: ${{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
channelId: ${{ github.ref_name == 'main' && 'live'

|| github.ref_name == 'staging' && 'staging' || format('pr-{0}', github.run_id) }}
          projectId: my-project

Usage example: Pushing to feature/xyz creates a preview URL like my-project--pr-123456.web.app. The team can test before merging.

8. GitLab CI: Security Scanning with SAST and Secret Detection

Prompt: "Create a GitLab CI job that runs SAST (Static Application Security Testing) and secret detection using the official GitLab templates. The job should fail only if critical or high severity issues are found. Medium and low should be warnings only."

Why this prompt matters: Security scanning is mandatory in many regulated industries. GitLab provides built-in templates.

Example output (YAML snippet):

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml

sast:
  stage: test
  variables:
    SAST_EXCLUDED_ANALYZERS: semgrep
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  allow_failure:
    exit_codes:
      - 1
      - 2
  artifacts:
    reports:
      sast: gl-sast-report.json

secret_detection:
  stage: test
  variables:
    SECRET_DETECTION_HISTORIC_SCAN: 'true'
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  allow_failure:
    exit_codes:
      - 1

Usage example: The pipeline runs SAST only on main to save runner time. If a critical vulnerability is found, the job fails with exit code 1. Medium issues only warn (exit code 2 allowed).

9. ArgoCD: Webhook Trigger with GitHub

Prompt: "Configure an ArgoCD Application to automatically sync when a new commit is pushed to the main branch of a GitHub repository. Include the webhook secret and set up a syncPolicy with automated enabled. Also, show how to configure the GitHub webhook URL."

Why this prompt matters: ArgoCD can poll Git repos, but webhooks provide near-instant sync, reducing deployment latency.

Example output (YAML snippet):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-webhook
  annotations:
    notifications.argoproj.io/subscribe-on-sync-succeeded.slack: my-channel
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/myapp.git
    targetRevision: main
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      webhook:
        enabled: true
        secretRef:
          name: github-webhook-secret

Usage example: In GitHub, go to Settings > Webhooks > Add webhook. Payload URL: https://argocd.example.com/api/webhook/application. Secret: the value from the Kubernetes secret github-webhook-secret. ArgoCD syncs within seconds after a push.

10. GitHub Actions: Matrix Testing Across OS and Node Versions

Prompt: "Write a GitHub Actions workflow that runs unit tests on a matrix of three operating systems (ubuntu-latest, macos-latest, windows-latest) and three Node.js versions (18, 20, 22). The workflow should use strategy.fail-fast: false to continue even if one combination fails. Collect test results and upload them as artifacts."

Why this prompt matters: Cross-platform compatibility is critical for libraries and CLI tools. Matrix testing ensures coverage.

Example output (YAML snippet):

name: Cross-Platform Test
on: [push, pull_request]
jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        node: [18, 20, 22]
      fail-fast: false
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci
      - run: npm test
      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results-${{ matrix.os }}-${{ matrix.node }}
          path: test-results.xml

Usage example: If Node 18 on Windows fails, the other 8 combinations continue running. The final report shows exactly which combination failed, helping you fix platform-specific bugs.

Conclusion

These 10 prompts cover the most common pain points in CI/CD: multi-architecture builds, parallel testing, canary deployments, dependency management, environment gating, multi-cluster setups, preview deployments, security scanning, webhook integration, and matrix testing. By using these prompts as starting points, you can save hours of configuration time and avoid common pitfalls. Copy the prompt, adapt it to your project, and let the AI generate the boilerplate. Remember to always review the generated code for security and best practices. Start automating smarter today.

Do you have a specific CI/CD problem not covered here? Share it in the comments below, and we will create a custom prompt for you.