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

## Introduction Continuous Integration and Continuous Delivery (CI/CD) are the backbone of modern DevOps practices. They automate the building, testing, and deployment of code, enabling teams to release faster and with higher confidence. However, configuring CI/CD pipelines can be complex, especially when you need to orchestrate multiple tools, environments, and security checks. Over the past few years, the DevOps community has developed a set of reusable, battle-tested prompts — or templates — for three major CI/CD platforms: **GitHub Actions**, **GitLab CI**, and **ArgoCD**. These prompts help you standardize workflows, enforce best practices, and reduce boilerplate code. In this article, I’ll share 10 expert-level prompts, organized by platform, with real-world examples and explanations. By the end of this article, you’ll be able to copy, adapt, and combine these prompts to build robust CI/CD pipelines that handle everything from linting and testing to multi-environment deployments and rollbacks. ## Prerequisites Before diving into the prompts, ensure you have: - Basic understanding of YAML syntax - A GitHub, GitLab, or Kubernetes cluster (for ArgoCD) account - Familiarity with Docker and containerization ## 1. GitHub Actions: Multi-Environment Deploy with Environment Guards ### Task Deploy a Node.js application to staging and production environments, with manual approval gates and secret injection. ### Prompt ```yaml name: Multi-Environment Deploy on: push: branches: - main - develop jobs: build: runs-on: ubuntu-latest outputs: image: ${{ steps.build.outputs.image }} steps: - uses: actions/checkout@v4 - name: Build Docker image id: build run: | docker build -t myapp:${{ github.sha }} . echo "image=myapp:${{ github.sha }}" >> $GITHUB_OUTPUT - name: Push to registry run: | docker tag myapp:${{ github.sha }} myregistry.com/myapp:${{ github.sha }} docker push myregistry.com/myapp:${{ github.sha }} deploy-staging: needs: build environment: name: staging url: https://staging.myapp.com runs-on: ubuntu-latest steps: - name: Deploy to staging run: | echo "Deploying ${{ needs.build.outputs.image }} to staging" # Your deployment script here deploy-production: needs: deploy-staging environment: name: production url: https://myapp.com runs-on: ubuntu-latest steps: - name: Wait for approval uses: trstringer/manual-approval@v1 with: secret: ${{ secrets.APPROVAL_TOKEN }} approvers: admin,lead-dev - name: Deploy to production run: | echo "Deploying ${{ needs.build.outputs.image }} to production" ``` ### Example Result When you push to `main`, the pipeline builds the Docker image, pushes it to the registry, deploys to staging automatically, then waits for a manual approval from `admin` or `lead-dev` before deploying to production. This prevents accidental releases and ensures only reviewed code reaches production. ## 2. GitHub Actions: Automated Dependency Scanning with Trivy ### Task Scan all pull requests for known vulnerabilities in dependencies using Trivy. ### Prompt ```yaml name: Dependency Scan on: pull_request: branches: [main] jobs: trivy-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@master with: scan-type: 'fs' scan-ref: '.' format: 'sarif' output: 'trivy-results.sarif' severity: 'CRITICAL,HIGH' - name: Upload Trivy results to GitHub Security uses: github/codeql-action/upload-sarif@v3 with: sarif_file: 'trivy-results.sarif' ``` ### Example Result On every pull request, Trivy scans the entire repository for vulnerable libraries. If any critical or high-severity vulnerabilities are found, they appear in the GitHub Security tab, and the pipeline can be configured to fail the PR. This prompt uses the official Trivy action from Aqua Security, which is widely adopted in the industry. ## 3. GitLab CI: Multi-Architecture Docker Build ### Task Build and push a Docker image for both `linux/amd64` and `linux/arm64` architectures using GitLab CI. ### Prompt ```yaml build-multiarch: stage: build image: docker:20.10.16 services: - docker:20.10.16-dind before_script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY script: - | docker buildx create --use docker buildx build --platform linux/amd64,linux/arm64 \ -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA \ -t $CI_REGISTRY_IMAGE:latest \ --push . only: - main ``` ### Example Result When code is merged to `main`, GitLab CI spins up a Docker-in-Docker service, creates a Buildx builder, and compiles the same Dockerfile for both x86 and ARM architectures. The resulting multi-arch manifest is pushed to the GitLab Container Registry. This is essential for teams that support both cloud VMs (amd64) and edge devices (arm64). ## 4. GitLab CI: Database Migration with Rollback ### Task Run database migrations before deployment, and provide an automatic rollback if the migration fails. ### Prompt ```yaml stages: - migrate - deploy - rollback migrate: stage: migrate image: node:18-alpine script: - npm install - npx sequelize-cli db:migrate variables: DATABASE_URL: $STAGING_DATABASE_URL only: - main rollback: stage: rollback image: node:18-alpine script: - npm install - npx sequelize-cli db:migrate:undo:all when: on_failure needs: ["migrate"] variables: DATABASE_URL: $STAGING_DATABASE_URL only: - main ``` ### Example Result If the `migrate` job fails (e.g., due to a broken migration script), the `rollback` job automatically runs and undoes all migrations. This prevents the application from being deployed with an inconsistent database schema. The `on_failure` trigger is a GitLab CI feature that ensures rollback happens only when the migration fails. ## 5. ArgoCD: ApplicationSet with Multiple Clusters ### Task Deploy the same application to multiple Kubernetes clusters using ArgoCD ApplicationSet with a generator that reads cluster metadata. ### Prompt ```yaml apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: myapp-clusters spec: generators: - clusters: selector: matchLabels: environment: production template: metadata: name: '{{name}}-myapp' spec: project: default source: repoURL: https://github.com/myorg/myapp-config targetRevision: HEAD path: overlays/{{name}} destination: server: '{{server}}' namespace: myapp syncPolicy: automated: prune: true selfHeal: true ``` ### Example Result ArgoCD watches all clusters labeled `environment: production`. For each cluster, it creates an Application that syncs the kustomize overlay specific to that cluster. If you add a new production cluster with the correct label, ArgoCD automatically deploys the app to it — no manual configuration needed. This is a powerful pattern for multi-cluster GitOps. ## 6. ArgoCD: Sync Wave with Database Migration ### Task Run a database migration job before the main application deployment, and ensure the application only starts after the migration completes. ### Prompt ```yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp spec: project: default source: repoURL: https://github.com/myorg/myapp-manifests targetRevision: HEAD path: . destination: server: https://kubernetes.default.svc namespace: myapp syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true sync: waves: - group: 1 resources: - kind: Job name: db-migration - group: 2 resources: - kind: Deployment name: myapp ``` ### Example Result ArgoCD syncs resources in groups. First, it runs the `db-migration` Job. Only after that Job completes successfully does it deploy the main `myapp` Deployment. If the migration fails, ArgoCD stops and does not deploy the app, preventing schema mismatches. This approach uses ArgoCD’s sync waves feature, which is well-documented in the official ArgoCD documentation. ## 7. GitHub Actions + ArgoCD: Trigger GitOps Sync ### Task After a successful GitHub Actions build, trigger ArgoCD to sync the application in the cluster. ### Prompt ```yaml name: Build and Trigger ArgoCD on: push: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build and push image run: | docker build -t myapp:${{ github.sha }} . docker push myregistry.com/myapp:${{ github.sha }} - name: Update manifest run: | sed -i "s|image: myapp:.*|image: myapp:${{ github.sha }}|" k8s/deployment.yaml git config user.name "CI" git config user.email "ci@example.com" git add k8s/deployment.yaml git commit -m "Update image to ${{ github.sha }}" git push ``` The last step updates the Kubernetes manifest in the GitOps repository. ArgoCD, which watches that repository, automatically syncs the change to the cluster. ### Example Result This creates a complete CI/CD pipeline: GitHub Actions builds the Docker image, updates the manifest file in a GitOps repo, and pushes the change. ArgoCD detects the drift and syncs the new image to the Kubernetes cluster. No direct access to the cluster is needed from the CI pipeline — a security best practice. ## 8. GitLab CI + ArgoCD: Multi-Environment Promotion with Gates ### Task Promote a build from staging to production using GitLab CI environment gates and ArgoCD ApplicationSets. ### Prompt ```yaml stages: - build - deploy-staging - promote-to-production build: stage: build script: - docker build -t myapp:$CI_COMMIT_SHORT_SHA . - docker push myregistry.com/myapp:$CI_COMMIT_SHORT_SHA deploy-staging: stage: deploy-staging script: - sed -i "s|image: myapp:.*|image: myapp:$CI_COMMIT_SHORT_SHA|" k8s/overlays/staging/deployment.yaml - git commit -m "Update staging image" - git push environment: name: staging promote-to-production: stage: promote-to-production script: - sed -i "s|image: myapp:.*|image: myapp:$CI_COMMIT_SHORT_SHA|" k8s/overlays/production/deployment.yaml - git commit -m "Update production image" - git push environment: name: production when: manual only: - main ``` ### Example Result On a push to `main`, GitLab CI builds the image and updates the staging overlay. After verifying the staging deployment, a developer manually triggers the `promote-to-production` job, which updates the production overlay. ArgoCD (configured with ApplicationSets pointing to these overlays) syncs both environments automatically. The manual gate prevents accidental production updates. ## 9. ArgoCD: Automated Rollback on Health Check Failure ### Task If a new deployment fails health checks, ArgoCD should automatically roll back to the previous stable version. ### Prompt ```yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp spec: project: default source: repoURL: https://github.com/myorg/myapp-manifests targetRevision: HEAD path: . destination: server: https://kubernetes.default.svc namespace: myapp syncPolicy: automated: prune: true selfHeal: true syncOptions: - Validate=false ignoreDifferences: - group: apps kind: Deployment jsonPointers: - /spec/replicas health: periodSeconds: 30 failureThreshold: 3 initialDelaySeconds: 60 ``` ### Example Result ArgoCD monitors the health of the deployed application. If the health check fails three times consecutively (e.g., the app crashes or liveness probe fails), ArgoCD automatically reverts the Deployment to the previous revision in the Git repository. This is a critical safety net for high-availability systems. Note: This requires proper health check endpoints in your application and correct liveness/readiness probes in the Deployment manifest. ## 10. GitHub Actions: Conditional Deployment Based on Commit Message ### Task Deploy to production only if the commit message contains `[deploy]`. ### Prompt ```yaml name: Conditional Deploy on: push: branches: [main] jobs: check-commit: runs-on: ubuntu-latest outputs: should-deploy: ${{ steps.check.outputs.should-deploy }} steps: - name: Check commit message id: check run: | if echo "${{ github.event.head_commit.message }}" | grep -q "\[deploy\]"; then echo "should-deploy=true" >> $GITHUB_OUTPUT else echo "should-deploy=false" >> $GITHUB_OUTPUT fi deploy: needs: check-commit if: needs.check-commit.outputs.should-deploy == 'true' runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Deploy to production run: | echo "Deploying because commit contains [deploy]" # Your deployment script ``` ### Example Result When you push to `main`, the pipeline checks if the commit message contains `[deploy]`. If it does, the `deploy` job runs. If not, the workflow passes without deployment. This gives you fine-grained control over production releases while still running other checks (tests, linting) on every push. ## Comparison Table | Feature | GitHub Actions | GitLab CI | ArgoCD | |---------|---------------|-----------|--------| | Environment gates | ✅ Manual approval | ✅ Manual jobs | ✅ Sync waves | | Multi-arch builds | ✅ Docker Buildx | ✅ Docker Buildx | ❌ (runs on cluster) | | Database migrations | ❌ (custom script) | ✅ (stages) | ✅ (sync waves) | | Multi-cluster deploy | ❌ (complex) | ❌ (complex) | ✅ (ApplicationSet) | | Rollback automation | ❌ (manual) | ❌ (manual) | ✅ (health checks) | | Conditional deploy | ✅ (commit message) | ✅ (rules) | ✅ (sync policy) | ## Best Practices 1. **Use environment-specific secrets**: Never hardcode credentials in your prompts. Use `secrets` in GitHub Actions, `variables` in GitLab CI, and `SealedSecrets` or `External Secrets Operator` with ArgoCD. 2. **Lock dependencies**: Pin action versions (e.g., `actions/checkout@v4`) and tool versions to prevent breaking changes. 3. **Add notifications**: Integrate Slack, Teams, or email alerts for pipeline failures using dedicated actions or webhooks. 4. **Keep pipelines fast**: Run parallel jobs for linting, unit tests, and security scans. Use caching for dependencies. 5. **Document your pipelines**: Add comments in YAML files and maintain a README for your CI/CD configuration. ## Conclusion These 10 prompts cover the most common CI/CD patterns used by DevOps teams today. By adopting them, you can standardize your pipelines across GitHub Actions, GitLab CI, and ArgoCD — reducing configuration errors and speeding up releases. Remember that CI/CD is not just about automation; it’s about reliability and safety. Use environment gates, rollback mechanisms, and security scanning to protect your production systems. Start with one or two prompts from this list, adapt them to your stack, and gradually build a complete pipeline that fits your team’s workflow. For further learning, explore the official documentation of each platform: - [GitHub Actions Documentation](https://docs.github.com/en/actions) - [GitLab CI Documentation](https://docs.gitlab.com/ee/ci/) - [ArgoCD Documentation](https://argo-cd.readthedocs.io/en/stable/) Happy deploying!

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

Comments

Recent articles

NYT Connections Hints and Answers for Saturday, July 4 (Game #1119): A Tech Tool Review for AI and Data Workflows

How to Integrate ASI Biont AI Agent with Mindbox: No-Code Automation for Customer Segmentation and Campaigns

OSDEV: Itanium ABI Part 1 – Array Operator new Cookies Demystified

This Slim Camera Has a Transparent LCD Screen for a Viewfinder: A Developer’s Honest Review

Nacon Introduces Budget Xbox Controller Line: A Developer’s Perspective on Affordability vs. Performance

Ask an AI Expert: What Exactly Is the Full Stack in the Age of Vibe Coding?

Google Cloud Architect — Professional (ACE + PCA): How to Master GCP in 90 Days with AI Training

From Raw Data to Trusted Insights: Building a Spark + dbt Pipeline with AI-Guided Learning

How to Supercharge Your Telegram Bot with ASI Biont AI Agent: No-Code Automation for Customer Support and Lead Qualification