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

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

Modern software delivery relies on automated CI/CD pipelines. Writing YAML for GitHub Actions, GitLab CI, or ArgoCD can be tedious, especially when you need to set up caching, OIDC, or multi-environment deployments. With the right prompts, AI assistants like ChatGPT, Claude, or GitHub Copilot can generate production-ready configs in seconds. This guide gives you 12 tested, copy-paste prompts that cover the most common CI/CD scenarios. Each prompt includes a sample output and practical tips. The prompts use official documentation as reference, so you can trust the results.

Why Prompt Engineering Matters for CI/CD

CI/CD configurations are declarative and structured. AI models are trained on millions of public repositories and official docs, making them surprisingly good at YAML generation. However, the quality of the output depends on the prompt. A vague prompt like "write a CI pipeline" often yields generic, unusable code. Specific prompts with context—language, platform, cloud provider, and desired behavior—produce accurate, security-conscious configs. The prompts below have been refined over many iterations. They assume you have at least a basic understanding of your CI/CD platform, but they include explanations for beginners.

GitHub Actions Prompts

1. Generate a Node.js CI Workflow

When to use: You need a standard CI pipeline for a Node.js project with tests, linting, and coverage.

Prompt:

Create a GitHub Actions workflow for a Node.js 20 project. It should run on push and pull_request. Use actions/setup-node@v4 with cache for npm. Run npm ci, npm run lint, npm test, and upload coverage to Codecov using actions/upload-artifact.

Sample output:

name: Node.js CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

Tip: Always include the exact version of actions (e.g., @v4) to ensure reproducibility.

2. Add Caching to Speed Up Your Workflow

When to use: Your current workflow is slow because dependencies are installed every run.

Prompt:

Modify this GitHub Actions workflow to add caching for pip, npm, and Docker layers. Use actions/cache@v4. The workflow builds a Python project and a React frontend.

[Paste your current workflow]

Sample output:

- uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('frontend/package-lock.json') }}

Tip: For setup-node and setup-python, the official actions already support caching out of the box; use the cache input.

3. Deploy to AWS with OIDC (No Long-Lived Secrets)

When to use: You’re tired of managing AWS keys in GitHub secrets and want to use OIDC.

Prompt:

Write a GitHub Actions workflow that deploys a Docker container to an AWS ECS service using OIDC. The AWS IAM role ARN is arn:aws:iam::123456789012:role/github-actions-role. Use aws-actions/configure-aws-credentials@v4 with the role-to-assume input. Assume the Docker image is already built and pushed to ECR.

Sample output:

permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-role
          aws-region: us-east-1
      - run: aws ecs update-service --cluster my-cluster --service my-service --force-new-deployment

Tip: Refer to GitHub’s OIDC documentation for details on setting up the IAM trust policy.

4. Debug a Failing GitHub Actions Job

When to use: A workflow fails with a cryptic error, and you want to add diagnostic steps.

Prompt:

This GitHub Actions job fails at the "Deploy" step with "Error: No space left on device". Suggest steps to debug and fix. Include a minimal workflow that checks disk space, cleans up Docker images, and sets skip_cleanup to true.

Sample output:

- name: Check disk space
  run: df -h
- name: Clean Docker images
  run: docker system prune -a -f

Tip: Always gather the exact error message before prompting. The AI can recommend a solution in 3–5 minutes.

GitLab CI Prompts

5. Create a Three-Stage Pipeline (Build, Test, Deploy)

When to use: You’re new to GitLab CI and need a baseline.

Prompt:

Write a GitLab CI .gitlab-ci.yml file for a Java Maven project. Stages: build, test, deploy. Use maven:3.9-eclipse-temurin-17 image. Build job: mvn package. Test job: mvn test. Deploy job should only run on main branch and SSH into a server using variables $DEPLOY_HOST, $DEPLOY_USER, $SSH_PRIVATE_KEY.

Sample output:

stages:
  - build
  - test
  - deploy
variables:
  MAVEN_OPTS: "-Dmaven.repo.local=./.m2"
build:
  stage: build
  image: maven:3.9-eclipse-temurin-17
  script: mvn package
  artifacts:
    paths: ["target/*.jar"]
test:
  stage: test
  image: maven:3.9-eclipse-temurin-17
  script: mvn test
deploy:
  stage: deploy
  image: alpine
  only:
    - main
  script:
    - apk add openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
    - scp -r target/app.jar $DEPLOY_USER@$DEPLOY_HOST:/opt/app/

Tip: Use GitLab’s predefined variables ($CI_PROJECT_DIR, $CI_COMMIT_REF_NAME) to make scripts more portable.

6. Convert a GitHub Actions Workflow to GitLab CI

When to use: You’re migrating a project from GitHub to GitLab.

Prompt:

Convert this GitHub Actions workflow to GitLab CI. Keep the same steps: install dependencies, run tests, build Docker image, push to GitLab Container Registry. Use GitLab’s built-in DOCKER_AUTH_CONFIG and CI variables. [Paste the GitHub Actions YAML]

Sample output:

docker build:
  stage: build
  image: docker:latest
  services: ["docker:dind"]
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

Tip: GitLab’s "Include" feature and extends can help you avoid duplication across similar jobs.

7. Terraform Pipeline with Environment Promotion

When to use: You need to run Terraform plan/apply in a protected environment.

Prompt:

Create a GitLab CI pipeline for Terraform. Use the official terraform image. Stages: validate, plan, apply. The plan job should save the plan file as an artifact. The apply job should be manual, run only on main branch, and require approval. Use environment names "staging" and "production".

Sample output:

validate:
  stage: validate
  script: terraform validate
plan:
  stage: plan
  script:
    - terraform init
    - terraform plan -out=plan.tfplan
  artifacts:
    paths: ["plan.tfplan"]
apply:
  stage: apply
  script: terraform apply plan.tfplan
  environment:
    name: production
  when: manual
  only:
    - main

Tip: Store Terraform state remotely in GitLab-managed Terraform state. See GitLab docs.

ArgoCD Prompts

8. Create an Application Resource for a Helm Chart

When to use: You want to register a new app in ArgoCD.

Prompt:

Write an ArgoCD Application manifest for a Helm chart located in a Git repository at https://github.com/myorg/app-config. The target revision is main, destination server is https://kubernetes.default.svc, namespace is default. Use the Helm release name "myapp" and set the values file at values/prod.yaml. Set syncPolicy to automated prune with selfHeal enabled.

Sample output:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  source:
    repoURL: https://github.com/myorg/app-config
    targetRevision: main
    path: charts/myapp
    helm:
      releaseName: myapp
      valueFiles: ["values/prod.yaml"]
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Tip: Make sure your Git repository access is configured in ArgoCD (SSH or HTTPS credentials). See ArgoCD Application docs.

9. Generate a Sync Policy with Automated Pruning

When to use: You want to control how ArgoCD syncs and cleans up resources.

Prompt:

Create an ArgoCD syncPolicy for a production environment. It should allow automated sync, prune orphaned resources, self-heal, and include a sync window that blocks syncs on weekends. Use the argoproj.io/v1alpha1 kind and ApplicationSet for multiple environments.

Sample output:

syncPolicy:
  automated:
    prune: true
    selfHeal: true
    allowEmpty: false
  syncOptions:
    - CreateNamespace=true
  syncWindows:
    - kind: deny
      schedule: "0 0 * * SUN"
      duration: 24h
      applications:
        - "*-prod"

Tip: Sync windows are defined in the ApplicationSet template, not the Application resource. For more details, check the ArgoCD Sync Windows docs.

10. ApplicationSet for Multi-Environment Deployments

When to use: You have a microservice that needs to be deployed to staging, QA, and prod with slightly different values.

Prompt:

Write an ArgoCD ApplicationSet that generates an Application for each environment in the list [staging, qa, prod]. Each Application should point to the same Git repo, but use a different values file: values-<env>.yaml. Set the destination namespace to <env> and the cluster URL to the corresponding cluster in the list. Enable automated sync with self-healing.

Sample output:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp
spec:
  generators:
    - list:
        elements:
          - env: staging
            cluster: https://staging-cluster:6443
          - env: qa
            cluster: https://qa-cluster:6443
          - env: prod
            cluster: https://prod-cluster:6443
  template:
    metadata:
      name: "myapp-{{env}}"
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/app-config
        targetRevision: main
        path: charts/myapp
        helm:
          valueFiles: ["values-{{env}}.yaml"]
      destination:
        server: "{{cluster}}"
        namespace: "{{env}}"
      syncPolicy:
        automated:
          selfHeal: true

Tip: ApplicationSet supports generators like git and cluster, but the list generator is easiest for small teams. See ArgoCD ApplicationSet docs.

Cross-Platform Prompts

11. Refactor a Legacy CI Pipeline for Speed and Reliability

When to use: You inherited a monolithic pipeline and want to break it down.

Prompt:

Refactor this existing GitLab CI pipeline. It’s a single job that does everything. Split it into stages: build, test, deploy. Add caching, use `needs` to avoid waiting for unnecessary jobs, and add a timeout for each job. [Paste your pipeline]

Sample output:

stages: [build, test, deploy]
cache:
  paths: [".m2", "node_modules/"]
build:
  stage: build
  script: "make build"
test:
  stage: test
  needs: ["build"]
  script: "make test"
deploy:
  stage: deploy
  needs: ["test"]
  when: manual
  script: "make deploy"

Tip: Use needs to run jobs out of order, and timeout to prevent stuck jobs. In GitHub Actions, use jobs.<job_id>.timeout-minutes.

12. Health-Check and Rollback Strategy for ArgoCD with GitHub Actions

When to use: You want a Cloud-Native Canary rollout that verifies health after deploy.

Prompt:

Create a GitHub Actions workflow that triggers an ArgoCD sync for a specific application, waits for the health status to become "Healthy", and if the sync fails or times out, rollback to the previous sync revision. Use `argocd` CLI with `argocd sync`, `argocd app wait`, and `argocd app rollback`.

Sample output:

steps:
  - name: Trigger sync
    run: argocd app sync myapp
  - name: Wait for health
    run: argocd app wait myapp --health
  - name: Rollback on failure
    if: failure()
    run: argocd app rollback myapp $(argocd app history myapp --revision)

Tip: Never hardcode rollback revisions. Use the output of the previous step. Always test these commands locally first.

Conclusion

Using AI prompts for CI/CD can dramatically speed up pipeline development and reduce YAML syntax errors. The 12 prompts above cover the most common scenarios with GitHub Actions, GitLab CI, and ArgoCD. For best results, always include as much context as possible: your language, framework, cloud provider, and the exact error if you’re debugging. Remember to verify the generated config against official documentation and test it in a branch before merging.

If you need more specific guidance, refer to the official docs: GitHub Actions, GitLab CI, and ArgoCD. Now, if you have a tricky pipeline problem, try one of these prompts and see how much time it saves.