Introduction
Setting up a reliable CI/CD pipeline is one of the most critical tasks for modern DevOps teams. Whether you're using GitHub Actions, GitLab CI, or ArgoCD, the quality of your pipeline often depends on how well you define the automation logic. However, writing configuration files from scratch can be time-consuming and error-prone. This is where well-crafted prompts come in.
In this article, you'll find 10 ready-to-use prompts for CI/CD pipelines. Each prompt is designed to help you generate configuration snippets, troubleshoot issues, or design deployment strategies quickly. These prompts are tested with popular AI assistants (like ChatGPT, Claude, and GitHub Copilot) and are tailored for three major tools: GitHub Actions, GitLab CI, and ArgoCD.
1. GitHub Actions: Build and Test a Node.js Application
Prompt:
"Generate a GitHub Actions workflow that runs on push and pull request events for a Node.js application. The workflow should:
- Check out the code
- Set up Node.js version 18
- Install dependencies with npm ci
- Run linting with npm run lint
- Run unit tests with npm test
- Cache node_modules for faster subsequent runs
- Only run on the main and develop branches for push events, but on all branches for pull requests"
Explanation: This prompt covers a standard CI workflow for any Node.js project. It ensures code quality before merging.
Usage example: Paste this prompt into an AI assistant, and you'll get a ready-to-use .github/workflows/ci.yml file. For instance, the output will include a jobs section with a ci job that uses actions/checkout@v4 and actions/setup-node@v4, plus caching with actions/cache@v3.
2. GitLab CI: Multi-Environment Deployment with Variables
Prompt:
"Create a .gitlab-ci.yml file for deploying a Dockerized Python application to three environments: staging, pre-production, and production. The pipeline should:
- Use GitLab CI variables for environment-specific secrets (e.g., $STAGING_API_KEY, $PROD_API_KEY)
- Build a Docker image only once and reuse it across environments
- Deploy to staging automatically on every push to develop branch
- Deploy to pre-production only when a merge request is merged into main
- Deploy to production only when a Git tag with pattern v* is pushed
- Include a manual approval step before production deployment"
Explanation: This prompt helps you implement a safe, multi-environment deployment pipeline with environment-specific configuration.
Usage example: The AI will generate a pipeline with stages like build, test, deploy-staging, deploy-preprod, and deploy-prod. The deploy-prod job will have when: manual and only: tags.
3. ArgoCD: ApplicationSet for Multi-Cluster Deployments
Prompt:
"Write an ArgoCD ApplicationSet manifest that deploys a single microservice to three Kubernetes clusters (dev, staging, prod). The ApplicationSet should:
- Use a Git generator that reads a config/clusters.yaml file with cluster names and API server URLs
- Generate an Application for each cluster
- Set the destination namespace to the cluster name (e.g., 'dev' namespace for dev cluster)
- Use the same Helm chart from charts/my-service/ for all clusters
- Override the Helm values per cluster using a file named values-{{name}}.yaml where {{name}} is the cluster name"
Explanation: This prompt simplifies managing multi-cluster deployments with ArgoCD, ensuring consistency across environments.
Usage example: The generated YAML will include spec.generators[0].git with a repoURL and revision, plus a template that references {{name}} in the destination namespace. You can place this in an applicationset.yaml file.
4. GitHub Actions: Conditional Deployment with Manual Approval
Prompt:
"Create a GitHub Actions workflow for a Java Spring Boot application with Maven. The workflow should:
- Build and test on every push to any branch
- Package the application into a JAR file
- Deploy to an AWS EC2 instance using SSH only when a release is created in GitHub
- Include a manual approval step using a GitHub environment called 'production' with required reviewers
- Use the aws-actions/configure-aws-credentials@v4 action to assume an IAM role for EC2 access"
Explanation: This prompt combines CI with conditional deployment and security best practices (IAM roles, manual approval).
Usage example: The output will include a release trigger and a deploy job that references environment: production. It will also show how to use secrets.AWS_ROLE_ARN and secrets.EC2_HOST.
5. GitLab CI: Parallel Testing with Matrix Jobs
Prompt:
"Write a .gitlab-ci.yml pipeline that runs unit tests and integration tests in parallel for a Ruby on Rails application. The pipeline should:
- Use a parallel:matrix job to run tests against three Ruby versions (3.0, 3.1, 3.2) and three PostgreSQL versions (13, 14, 15)
- Cache the vendor/bundle directory based on the Ruby version
- Run RuboCop linting as a separate job that doesn't depend on the matrix
- Store test reports as artifacts with reports:junit so GitLab shows them in merge requests"
Explanation: Matrix jobs help you test across multiple environments without duplicating code.
Usage example: The AI will generate a tests job with parallel:matrix containing RUBY_VERSION and PG_VERSION variables, plus cache:key using $RUBY_VERSION. The rubocop job will run in parallel.
6. ArgoCD: Sync Wave for Database Migrations
Prompt:
"Create an ArgoCD Application manifest that deploys a Django application with a database migration job. The manifest should:
- Use sync waves: wave 0 for a ConfigMap and Secret, wave 1 for a Job that runs Django migrations, wave 2 for the Deployment and Service
- Set the Job to ttlSecondsAfterFinished: 300 so it's automatically cleaned up
- Add a pre-sync hook for the migration Job
- Use the argocd.argoproj.io/sync-wave annotation for ordering"
Explanation: Sync waves ensure dependencies are deployed in the correct order (e.g., database migration before app rollout).
Usage example: The generated YAML will include metadata.annotations with argocd.argoproj.io/sync-wave: "0" for the ConfigMap, "1" for the Job, and "2" for the Deployment. The Job will have hooks: [PreSync].
7. GitHub Actions: Multi-Architecture Docker Build
Prompt:
"Generate a GitHub Actions workflow that builds and pushes a Docker image for both linux/amd64 and linux/arm64 architectures. The workflow should:
- Trigger on push to main and on new tags
- Use docker/setup-qemu-action@v3 and docker/setup-buildx-action@v3 for multi-architecture support
- Build the image using a Dockerfile in the repository root
- Push the image to Docker Hub using the docker/login-action@v3
- Tag the image with latest for pushes to main, and with the Git tag for tagged pushes"
Explanation: This prompt is essential for teams targeting both x86 and ARM (e.g., Apple Silicon, AWS Graviton) environments.
Usage example: The output will include a build-and-push job with platforms: linux/amd64,linux/arm64. It will also show how to use secrets.DOCKER_USERNAME and secrets.DOCKER_PASSWORD.
8. GitLab CI: Auto-DevOps with Custom Helm Values
Prompt:
"Create a .gitlab-ci.yml that extends GitLab's Auto-DevOps template but overrides the Helm chart values. Specifically:
- Set the replica count to 3 for production, 1 for staging
- Add a custom environment variable DATABASE_URL that comes from a GitLab CI variable
- Disable the built-in POSTGRES_ENABLED feature (set it to false)
- Use the KUBE_INGRESS_BASE_DOMAIN variable for the ingress host
- Run only the build, test, and deploy stages, skipping review and dast"
Explanation: Auto-DevOps provides a quick start, but often needs customization. This prompt shows how to override defaults safely.
Usage example: The generated YAML will include include: template: Auto-DevOps.gitlab-ci.yml and a variables section that overrides HELM_UPGRADE_EXTRA_ARGS with --set replicaCount=3 --set postgresql.enabled=false.
9. ArgoCD: Rollback with Prune and Self-Heal
Prompt:
"Write an ArgoCD Application manifest for a microservice that uses a Helm chart from a private Git repository. The Application should:
- Enable selfHeal and prune in the sync policy
- Set syncPolicy.automated.allowEmpty to true (to allow empty charts)
- Use a retry strategy with limit: 5 and backoff duration 10s
- Configure the destination to be the production namespace on the prod-cluster
- Point the source to a Git repo with path charts/api-gateway and revision HEAD"
Explanation: Self-heal and prune are critical for GitOps to automatically correct drift and remove outdated resources.
Usage example: The output will include syncPolicy.automated with prune: true, selfHeal: true, and a retry block under syncPolicy. This ensures the cluster always matches the Git state.
10. Multi-Tool: Security Scanning in CI/CD
Prompt:
"Generate a CI/CD pipeline that runs security scanning on every push for a Node.js application. The pipeline should:
- Use GitHub Actions for the CI runner
- Run npm audit to check for dependency vulnerabilities
- Run a SAST (Static Application Security Testing) tool (like semgrep) on the code
- Run a container scan using trivy on the Docker image after building
- Fail the pipeline if any critical vulnerabilities are found
- Post the results as a comment on the pull request using the github-script action"
Explanation: Security scanning is a must-have in modern pipelines. This prompt combines multiple tools in one workflow.
Usage example: The AI will generate a workflow with three jobs: audit, sast, and container-scan. The container-scan job will use aquasecurity/trivy-action@master with exit-code: '1' to fail on critical issues. The github-script action will use context.payload.pull_request.number to add a comment.
Conclusion
CI/CD pipelines are the backbone of modern software delivery, and using prompts can dramatically speed up your configuration process. The 10 prompts above cover the most common scenarios: from basic builds to multi-cluster deployments and security scanning. Remember to always review auto-generated configurations for security and correctness—never blindly copy-paste into production.
For teams looking to integrate these pipelines with advanced analytics and monitoring, ASI Biont supports connecting CI/CD tools via API. For example, you can automatically send pipeline metrics from GitHub Actions or GitLab CI to track deployment frequency and failure rates. This helps you measure the effectiveness of your DevOps practices over time.
Comments