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

You're staring at a failed pipeline, again. The error logs are cryptic, the YAML indentation is off, and your deployment to Kubernetes just rolled back. If this sounds familiar, you're not alone. CI/CD pipelines are powerful but notoriously finicky to get right. Fortunately, AI assistants trained on vast amounts of public code and documentation can now help you write, debug, and optimize your workflows in minutes. This article collects 12 battle-tested prompts you can use with tools like ChatGPT, Claude, or GitHub Copilot to streamline your work with GitHub Actions, GitLab CI, and ArgoCD. Each prompt includes the exact phrasing, a concrete task, and a realistic example output. Whether you're new to continuous integration or orchestrating multi-cluster GitOps, these prompts will save you hours.

Basic Prompts

1. Generate a Simple GitHub Actions Workflow for Node.js

Task: You need a workflow that installs dependencies, runs tests, and uploads test reports on every push.

Prompt:
"Create a GitHub Actions workflow for a Node.js 20 project using pnpm. The workflow should trigger on push and pull_request to main. It should install dependencies, run linting, run unit tests with coverage, and upload the coverage report as an artifact. Include a concurrency group that cancels in-progress runs for the same branch. Use official actions like actions/checkout@v4 and actions/setup-node@v4."

Example Result:
The AI should produce a .github/workflows/ci.yml file similar to:

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm test -- --coverage
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: coverage
          path: coverage/

Why it works: This prompt specifies the runtime, package manager, trigger events, and required steps. It also asks for concurrency control, a best practice that prevents wasted compute. According to the GitHub Actions documentation, the concurrency key is supported in all workflows and is critical for teams with high pull-request volume.

2. Create a GitLab CI Pipeline for Python

Task: You want a simple pipeline that runs with python:3.12-slim, installs pytest, executes tests, and reports coverage as a CI artifact.

Prompt:
"Write a GitLab CI pipeline for a Python 3.12 project using poetry. The pipeline must have two stages: test and report. The test stage should install dependencies, run pytest with coverage, and upload the coverage XML as an artifact. The report stage should print a summary of the coverage report. Use the default runner tags."

Example Result:

stages:
  - test
  - report

variables:
  POETRY_VERSION: "1.8.3"

test:
  stage: test
  image: python:3.12-slim
  before_script:
    - pip install poetry==$POETRY_VERSION
    - poetry install --with dev
  script:
    - poetry run pytest --cov --cov-report=xml --cov-report=term-missing
  artifacts:
    paths:
      - coverage.xml
    expire_in: 1 week

report:
  stage: report
  image: python:3.12-slim
  script:
    - pip install coverage
    - coverage report --data-file=.coverage
  needs: ["test"]
  only:
    - main

Why it works: The prompt clearly defines stages, images, and artifact handling. The needs keyword is a valuable feature in GitLab CI that allows DAG execution, reducing pipeline runtime significantly. See the GitLab CI documentation for details.

3. Explain the Difference Between GitHub Actions and GitLab CI

Task: You're writing documentation or evaluating tools and need a concise comparison.

Prompt:
"Compare GitHub Actions and GitLab CI for a small team of five developers. Focus on hosted runner options, YAML syntax, built-in features for container registry, and integration with Kubernetes. Provide a table with the key differences and a paragraph summarizing which one is better for a startup."

Example Result:
A table like this:

A summary paragraph that says GitLab is more self-contained for a full DevOps lifecycle, while GitHub Actions is simpler for developers already on GitHub. This is based on official documentation: GitHub Actions and GitLab CI/CD.

Advanced Prompts

4. Optimize GitHub Actions Caching for Dependency Installation

Task: Your workflow is slow because it re-downloads dependencies every time. You need steps that cache node_modules across builds.

Prompt:
"Enhance a GitHub Actions workflow for a Node.js project to use dependency caching. The project uses npm. Add a step that caches the npm cache directory using actions/cache with a key based on package-lock.json's hash. Also, ensure that the cache is restored before npm ci. Show the full updated workflow."

Example Result:

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: 20
  - uses: actions/cache@v4
    with:
      path: ~/.npm
      key: npm-${{ hashFiles('package-lock.json') }}
      restore-keys: |
        npm-
  - run: npm ci

Why it works: Caching reduces workflow time. The hashFiles function creates a unique key per lock file, invalidating cache only when dependencies change. This approach is recommended in the GitHub Actions caching guide.

5. Implement a Multi-Stage Docker Build in GitLab CI

Task: You need a pipeline that builds a Docker image using a multi-stage Dockerfile and pushes it to the GitLab Container Registry.

Prompt:
"Create a GitLab CI job that builds a multi-stage Dockerfile for a Go application. The job should use the kaniko executor to build the image without a Docker daemon, tag it with the branch name and commit SHA, and push it to the registry on the main branch. Also add a dependencies and only clause."

Example Result:

build:
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  stage: build
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  only:
    - main

Why it works: Kaniko is the official way to build container images in unprivileged GitLab CI environments. Refer to the GitLab Docker integration documentation for more details.

6. Set Up a GitOps Deployment with ArgoCD and a GitHub Actions Trigger

Task: You want to automatically sync a Kubernetes app via ArgoCD whenever you push a new image to GHCR.

Prompt:
"Design a GitHub Actions workflow that builds a Docker image, pushes it to GitHub Container Registry, and then triggers a sync in ArgoCD by using the argocd CLI. The workflow should update a kustomize image in the config repo or use the argocd app sync command with the insecure option. Include installation of argo CD cli via actions/checkout and curl."

Example Result:

deploy:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: |
        curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
        chmod +x argocd-linux-amd64
        sudo mv argocd-linux-amd64 /usr/local/bin/argocd
    - run: |
        argocd login $ARGOCD_SERVER --username $ARGOCD_USERNAME --password $ARGOCD_PASSWORD --insecure
        argocd app sync $APP_NAME --server $ARGOCD_SERVER --insecure
      env:
        ARGOCD_SERVER: ${{ secrets.ARGOCD_SERVER }}
        ARGOCD_USERNAME: ${{ secrets.ARGOCD_USERNAME }}
        ARGOCD_PASSWORD: ${{ secrets.ARGOCD_PASSWORD }}

Why it works: The ArgoCD CLI is available via the official release assets. The prompt explicitly requests the latest version download and uses secrets for credentials. For best practices, consider using the argocd-image-updater.

7. Debug a Failing GitHub Actions Job from a Log Snippet

Task: You have a cryptic error message and want the AI to help you diagnose it.

Prompt:
"Here is a log snippet from my GitHub Actions workflow. The job fails at the 'Run tests' step. Explain the probable cause and suggest fixes. The error is:

Error: Process completed with exit code 1.
> myproject@1.0.0 test: jest --ci
> jest --ci

 FAIL  tests/api.test.js
  ● GET /api/user › returns 401 without token

    expect(received).toBe(expected) // Object.is equality

    Expected: 200
    Received: 401

The environment has NODE_ENV=development. What is wrong?"

Example Result:
The AI should explain that your test expects a 200 status but the API returns 401, meaning the test is missing authentication/authorization. The fix is to mock a JWT token or set the right authorization header in the test setup. It might also suggest checking the Jest config for modules that need mocking.

Why it works: This is a classic prompt using the "few-shot" technique. By providing the exact log and the context, the AI can reason about the failure. GitHub docs recommend checking the troubleshooting guide.

Expert Prompts

8. Design a Canary Deployment Strategy with ArgoCD and AnalysisTemplate

Task: You need progressive delivery: roll out 5% of traffic, analyze metrics, then shift to 100% if successful.

Prompt:
"Create an Argo Rollouts manifest for a service called 'my-app' with a canary strategy. Include two steps: first set weight to 20% and pause for 5m, then set weight to 100%. Add an AnalysisTemplate that queries Prometheus for the HTTP error rate. The rollout should use the stable Service and a preview Service. Write the full YAML."

Example Result:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v2
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {duration: 5m}
      - setWeight: 100
      analysis:
        templates:
        - templateName: my-error-rate
        args:
        - name: service
          value: my-app
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: my-error-rate
spec:
  metrics:
  - name: error-rate
    interval: 1m
    successCondition: result < 0.05
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc:9090
        query: |
          sum(rate(http_requests_total{status=~"5..", service="{{args.service}}"}[5m]))
          / sum(rate(http_requests_total{service="{{args.service}}"}[5m]))

Why it works: Argo Rollouts is the standard for progressive delivery in Kubernetes. The AnalysisTemplate uses PromQL to compare 5xx responses to total traffic. For more details, see the Argo Rollouts documentation.

9. Create a Matrix Build Strategy for Multiple Versions in GitLab CI

Task: You need to test your library against several Python versions (3.9, 3.10, 3.11, 3.12) and multiple OSes.

Prompt:
"Write a GitLab CI job that runs a matrix of tests across Python 3.9 through 3.12 and Ubuntu vs. Alpine. Use the parallel:matrix keyword. The job should install dependencies with pip and run pytest. Show the full job definition."

Example Result:

test:
  parallel:
    matrix:
      - PYTHON_VERSION: ["3.9", "3.10", "3.11", "3.12"]
        VARIANT: ["-slim", "-alpine"]
  image: python:${PYTHON_VERSION}${VARIANT}
  script:
    - pip install -r requirements.txt
    - pytest

Why it works: Matrix builds are supported in GitLab CI via parallel:matrix. Ensure the image tags are valid (e.g., python:3.9-slim). See the GitLab CI matrix documentation for syntax details.

10. Write a Reusable GitHub Action Composite Action

Task: You have a common step that you want to reuse across workflows, e.g., setting up a specific tool and logging in to a registry.

Prompt:
"Create a composite action in a GitHub repo under .github/actions/setup-tool. The action takes an input called tool-version and uses a run step to download the tool. It should cache the downloaded binary. Output the full action.yml file."

Example Result:

name: 'Setup My Tool'
description: 'Downloads and caches a custom binary'
inputs:
  tool-version:
    description: 'Version of the tool'
    required: true
    default: '1.0.0'
runs:
  using: 'composite'
  steps:
    - name: Cache tool
      id: cache
      uses: actions/cache@v4
      with:
        path: ~/.local/bin
        key: tool-${{ inputs.tool-version }}
    - name: Install tool
      if: steps.cache.outputs.cache-hit != 'true'
      run: |
        curl -L -o /tmp/tool.tar.gz https://example.com/tool-${{ inputs.tool-version }}.tar.gz
        tar -xzf /tmp/tool.tar.gz -C ~/.local/bin
      shell: bash

Why it works: Composite actions help reduce duplication and are a best practice recommended by GitHub. See the GitHub Actions metadata syntax documentation.

11. Ensure Secure Secrets Management in CI/CD Pipelines

Task: You want to audit your pipelines for security anti-patterns like hardcoded secrets, use of GitHub token scope, and potential exposure of env vars.

Prompt:
"Review this GitHub Actions workflow for security issues. Suggest changes to avoid accidental secret exposure and improve the principle of least privilege. The workflow uses ${{ secrets.DEPLOY_KEY }} in a run step and sets env globally. Also, check if the GITHUB_TOKEN permissions are spelled correctly. Write the corrected workflow."

Example Result:
The AI should point out that env at the workflow level is visible to all steps, and suggest moving it to the specific step. It should also recommend setting permissions: contents: read at the top. For example:

permissions:
  contents: read
jobs:
  deploy:
    steps:
      - name: Deploy
        run: ./deploy.sh
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

This aligns with the GitHub Actions security hardening guide.

12. Auto-Generate Release Notes Based on Conventional Commits in CI

Task: You want to automate release notes generation in a GitLab CI pipeline, using the commit history from main to the last tag.

Prompt:
"Create a GitLab CI job that uses the release-cli to generate release notes. The job should be triggered on push to a tag with pattern v*. Use $CI_COMMIT_TAG and $CI_COMMIT_BEFORE_DESCRIPTION. Also, extract the changelog from a CHANGELOG.md file if it exists. The example should include the variables and git push of the tag."

Example Result:

release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
  script:
    - release-cli create --name "Release $CI_COMMIT_TAG" --description "Changes in $CI_COMMIT_TAG: $(git log --oneline --follow CHANGELOG.md -1)" --tag-name $CI_COMMIT_TAG

Why it works: This uses the official release-cli. Many teams generate release notes from a CHANGELOG.md with awk to extract the section for the version. Refer to the GitLab release-cli documentation.

Conclusion

These 12 prompts cover the full spectrum of CI/CD tasks—from writing simple workflows to designing complex progressive delivery strategies. The key to getting the most out of AI is to be as specific as possible: mention the exact tools, versions, and expected outcomes. Always review generated YAML for security and correctness, as AI is a powerful assistant, not a replacement for human judgment. With these prompts, you can now automate your automation and ship faster without breaking things.