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

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

Introduction

Building a reliable CI/CD pipeline is no longer optional — it’s the backbone of modern software delivery. Whether you use GitHub Actions, GitLab CI, or ArgoCD, having a library of reusable, battle-tested configuration snippets (“prompts”) can save hours of debugging and accelerate your team’s velocity. This article provides 15 practical prompts, organised by complexity: basic, advanced, and expert. Each prompt includes the exact code, the problem it solves, and the expected outcome. All examples are based on official documentation and real-world usage.

Basic Prompts

1. GitHub Actions: Simple Build and Test

Task: Run unit tests on every push to any branch.

Prompt (.github/workflows/test.yml):

name: Tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

Result: Every push triggers a run. If tests fail, the commit is flagged red. This prompt uses actions/checkout and actions/setup-node — both verified by GitHub (source: GitHub Actions docs).

2. GitLab CI: Lint and Test with Merge Request

Task: Run linting and tests automatically when a merge request is opened.

Prompt (.gitlab-ci.yml):

stages:
  - lint
  - test

lint:
  stage: lint
  image: node:20-alpine
  script:
    - npm ci
    - npm run lint
  only:
    - merge_requests

test:
  stage: test
  image: node:20-alpine
  script:
    - npm ci
    - npm test
  only:
    - merge_requests

Result: Both jobs run in parallel. Merge request cannot be merged until both pass. The only: merge_requests directive ensures pipelines aren’t wasted on branches without MRs.

3. ArgoCD: Sync an Application Automatically

Task: Keep a Kubernetes deployment in sync with a Git repository using automatic sync policy.

Prompt (Application manifest):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/my-app.git
    path: k8s
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Result: ArgoCD continuously monitors main branch. Any commit is automatically applied; resources that drift are reverted. The prune: true flag removes stale resources (source: ArgoCD User Guide).

4. GitHub Actions: Deploy to Kubernetes with kubectl

Task: After tests pass on the main branch, deploy to a Kubernetes cluster using a kubectl action.

Prompt:

name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set kubeconfig
        run: echo "${{ secrets.KUBECONFIG }}" > kubeconfig
      - name: Deploy
        run: kubectl apply -f k8s/ --kubeconfig=kubeconfig

Result: On every push to main, the new manifests are applied. The kubeconfig is stored as a secret — never exposed in code.

5. GitLab CI: Multi-Stage Build and Push to Docker Registry

Task: Build a Docker image and push to GitLab Container Registry only on tags.

Prompt:

stages:
  - build
  - push

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG .
  only:
    - tags

push:
  stage: push
  image: docker:24
  services:
    - docker:24-dind
  script:
    - echo $CI_REGISTRY_PASSWORD | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
  only:
    - tags

Result: When a tag is pushed, the image is built and automatically published. GitLab CI provides $CI_REGISTRY_USER and $CI_REGISTRY_PASSWORD built-in variables.

Advanced Prompts

6. GitHub Actions: Matrix Build Across Multiple Versions

Task: Run tests on Node 18, 20, and 22 simultaneously.

Prompt:

name: Matrix Test
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci && npm test

Result: Three parallel runners test each version. Failures on one version don’t block others. Matrix strategy is documented in GitHub Actions docs.

7. GitLab CI: Conditional Jobs with Rules

Task: Run a security scan only on merge requests that modify package.json.

Prompt:

security-scan:
  stage: test
  image: node:20-alpine
  script:
    - npm audit
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - package.json

Result: The job only runs when the MR includes changes to package.json. No wasted compute for unrelated changes.

8. ArgoCD: Sync Waves and Resource Hooks

Task: Deploy a database migration Job before the application Deployment, and wait for it to complete.

Prompt (Application with sync waves):

spec:
  source:
    repoURL: https://github.com/example/my-app.git
    path: manifests
  syncPolicy:
    automated:
      prune: true
  syncWaves:
    - wave: 1
      resources:
        - kind: Job
          name: db-migration
    - wave: 2
      resources:
        - kind: Deployment
          name: app

Result: ArgoCD first applies the Job (wave 1), waits for success, then applies the Deployment. This prevents app pods from starting before migrations run.

9. GitHub Actions: Reusable Workflow with Inputs

Task: Create a reusable workflow for linting that can be called from multiple repositories.

Prompt (.github/workflows/lint.yml in central repo):

name: Lint Reusable
on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
      - run: npm ci && npm run lint

Result: Any repo can call this workflow with uses: org/lint-repo/.github/workflows/lint.yml@v1 and pass node-version. Reduces duplication across dozens of repos.

10. GitLab CI: Secrets Outside Variables via Vault Integration

Task: Fetch database password from HashiCorp Vault at pipeline runtime.

Prompt:

variables:
  VAULT_ADDR: https://vault.example.com
db-migrate:
  stage: deploy
  image: vault:1.13
  script:
    - vault login -method=token token=$VAULT_TOKEN
    - export DB_PASSWORD=$(vault kv get -field=password secret/db)
    - ./migrate.sh

Result: The password never appears in job logs or CI settings. The token is stored as a masked CI/CD variable.

Expert Prompts

11. GitHub Actions: Self-Hosted Runner on AWS EC2

Task: Launch an ephemeral self-hosted runner using Terraform and register it automatically.

Prompt:

name: Setup Runner
on:
  workflow_dispatch:
jobs:
  create-runner:
    runs-on: ubuntu-latest
    steps:
      - name: Terraform Apply
        run: |
          cd terraform/runner
          terraform init && terraform apply -auto-approve
          RUNNER_TOKEN=$(curl -s -X POST -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" https://api.github.com/repos/${{ github.repository }}/actions/runners/registration-token | jq -r .token)
          terraform apply -auto-approve -var="runner_token=$RUNNER_TOKEN"

Result: A fresh EC2 instance registers as a self-hosted runner, runs next jobs, then terminates. Fine-grained control over hardware.

12. GitLab CI: Deploy to Kubernetes with GitLab Agent (CI/CD Tunnel)

Task: Use GitLab Agent for Kubernetes for secure deployments without exposing cluster endpoint.

Prompt:

stages:
  - deploy

deploy-to-k8s:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl config use-context my-project/my-agent
    - kubectl apply -f manifests/
  environment:
    name: production

Result: The connection goes through the GitLab Agent tunnel; no need to store kubeconfig. The agent is registered once per cluster (see GitLab Agent docs).

13. ArgoCD: ApplicationSet with Cluster Generator

Task: Deploy the same application to multiple clusters automatically when a new cluster is added.

Prompt (ApplicationSet):

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-cluster-app
spec:
  generators:
    - clusters: {}
  template:
    metadata:
      name: '{{name}}-app'
    spec:
      project: default
      source:
        repoURL: https://github.com/example/app.git
        targetRevision: main
        path: k8s
      destination:
        server: '{{server}}'
        namespace: production

Result: Every cluster registered in ArgoCD gets the application. Adding a new cluster automatically triggers a sync. Great for multi-region deployments.

14. GitHub Actions: Continuous Delivery with Environments and Approvals

Task: Deploy to staging automatically, but require manual approval for production.

Prompt:

name: CD Pipeline
on:
  push:
    branches: [main]
jobs:
  staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: echo "Deploy to staging"
  production:
    needs: staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://app.example.com
    steps:
      - run: echo "Deploy to production"

Result: The environment: production block enforces required reviewers defined in repository settings. Pipeline pauses until approval.

15. GitLab CI: Manual Approval Gate with Webhook Notification

Task: Send a Slack notification asking for approval before deploying to production.

Prompt:

stages:
  - build
  - approve
  - deploy

build:
  stage: build
  script: echo "Building..."

approve:
  stage: approve
  script:
    - curl -X POST $SLACK_WEBHOOK -H 'Content-Type: application/json' -d '{"text":"Approve deployment? Go to <URL>"}'
  when: manual
  allow_failure: false

deploy:
  stage: deploy
  script: echo "Deploying..."
  needs: [approve]

Result: The pipeline pauses at the approve stage. A human clicks the manual trigger in GitLab UI (or via Slack action). Only then does deploy run.

Conclusion

These 15 prompts cover the spectrum from a simple test-and-build workflow to multi-cluster ApplicationSets with manual approval gates. By using them as starting points, you can avoid common pitfalls and adopt industry-proven patterns. The key is to start small — pick one prompt that matches your current bottleneck, adapt it, and iterate. Explore the official documentation for each tool to deepen your understanding:

• GitHub Actions Workflow Syntax
• GitLab CI YAML Reference
• ArgoCD Documentation

Now go automate — your future self will thank you.