15 промтов для настройки CI/CD: GitHub Actions, GitLab CI и ArgoCD

15 промтов для настройки CI/CD: GitHub Actions, GitLab CI и ArgoCD

Введение

Каждый DevOps-инженер знает: написание конфигураций для CI/CD — это постоянная рутина. Однотипные блоки, десятки строк YAML, ошибки в отступах и забытые секреты. Но с появлением генеративных AI-моделей (например, GPT-4, Claude, Gemini) у нас появился инструмент, который может за минуты выдать рабочий пайплайн под конкретную задачу. Главное — правильно задать вопрос. Эта статья — коллекция проверенных промтов для трёх самых популярных инструментов: GitHub Actions, GitLab CI и ArgoCD. Каждый промт я тестировал лично, адаптировал под реальные проекты и готов поделиться готовыми шаблонами. Бери и используй.

Промты для GitHub Actions

GitHub Actions — самый распространённый CI/CD для репозиториев на GitHub. Вот четыре промта, которые покрывают 80% типовых сценариев.

Промт 1: Базовый пайплайн сборки и тестирования Node.js

Цель: Сгенерировать workflow для сборки, линтинга и тестов Node.js-приложения.
Запрос: "Создай GitHub Actions workflow, который запускается на push и pull request в main. Используй Ubuntu latest, версию Node.js 20. Установи зависимости, запусти npm run lint и npm test. Настрой кэширование node_modules. Выведи артефакты (отчёты lint)."
Результат:

name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [20]
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint -- --format junit -o reports/junit.xml
      - run: npm test -- --coverage
      - name: Upload lint report
        uses: actions/upload-artifact@v4
        with:
          name: lint-report
          path: reports/

Пояснение: Промт явно указывает триггеры, кэширование и артефакты. AI понимает контекст «Node.js» и сам подбирает нужный шаг кэширования. В выводе — junit-отчёт для линта, который можно посмотреть в интерфейсе Actions.

Промт 2: Мультиконтейнерный пайплайн с Docker Compose

Цель: Собрать и протестировать приложение, которое требует базу данных (PostgreSQL) и Redis.
Запрос: "GitHub Actions workflow для приложения на Python (Django) с сервисами PostgreSQL 15 и Redis 7. Запусти Docker Compose, выполни миграции, прогнать тесты, останови контейнеры. Добавь health-check для PostgreSQL."
Результат:

name: Django CI

on: [push, pull_request]

env:
  POSTGRES_USER: postgres
  POSTGRES_PASSWORD: postgres
  POSTGRES_DB: test_db

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: test_db
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432
      redis:
        image: redis:7
        ports:
          - 6379:6379
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python 3.11
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install -r requirements.txt
      - run: python manage.py migrate
      - run: python manage.py test

Пояснение: Промт использует ключевые слова «health-check» и «сервисы» — AI предлагает штатную секцию services с health-check. Вариант без Docker Compose (прямое объявление сервисов) часто надёжнее, так как не требует установки Compose.

Промт 3: Многоэтапная сборка Docker-образа и публикация в Registry

Цель: Собрать многостадийный Docker-образ и пушить его в Docker Hub или GitHub Container Registry.
Запрос: "Workflow для сборки Docker-образа приложения на Go. Используй многостадийную сборку (сначала build, потом минимальный образ). Публикуй образ в ghcr.io с тегом git commit SHA. Настрой логин в GitHub Container Registry через секреты."
Результат:

name: Build and Push Docker image

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Пояснение: Промт явно указывает регистр (ghcr.io), тип кэша (GitHub Actions cache) и теги. AI автоматически добавляет кэш-слой, что ускоряет повторные сборки на 40–60%.

Промт 4: Deploy на AWS ECS с помощью ECS Deploy Action

Цель: Автоматически задеплоить новый образ в AWS ECS Fargate.
Запрос: "Workflow: после сборки Docker образа (push в ECR) выполни деплой в AWS ECS. Используй action aws-actions/amazon-ecs-deploy-task-definition. Задай cluster name: 'my-cluster', service name: 'my-service', container name: 'app'. Шаблон task definition храни в репозитории."
Результат:

name: Deploy to Amazon ECS

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
      - name: Build, tag, and push image to Amazon ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: my-app
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
      - name: Fill in the new image ID in the Amazon ECS task definition
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: task-definition.json
          container-name: app
          image: ${{ steps.login-ecr.outputs.registry }}/my-app:${{ github.sha }}
      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          service: my-service
          cluster: my-cluster
          wait-for-service-stability: true

Пояснение: Промт задаёт полный pipeline: аутентификация, сборка, push в ECR, рендер task definition, деплой. WAIT-FOR-SERVICE-STABILITY — полезный флаг для проверки здоровья сервиса.

Промты для GitLab CI

GitLab CI имеет свой формат .gitlab-ci.yml. Вот четыре промта для частых сценариев.

Промт 5: Монолит с тестами и качеством кода

Цель: GitLab CI для монолитного Python-приложения с линтингом (flake8), тестами (pytest) и статическим анализом (bandit).
Запрос: "Напиши .gitlab-ci.yml для Python-приложения. Используй образ python:3.11. Стадии: lint, test, security. В стадии lint — flake8, в test — pytest с coverage, в security — bandit. Настрой кэширование pip."
Результат:

image: python:3.11

stages:
  - lint
  - test
  - security

cache:
  paths:
    - .cache/pip
    - venv/

before_script:
  - python -m venv venv
  - source venv/bin/activate
  - pip install -r requirements.txt

lint:
  stage: lint
  script:
    - pip install flake8
    - flake8 . --max-line-length=120 --statistics

test:
  stage: test
  script:
    - pip install pytest pytest-cov
    - pytest --cov=app --cov-report=term-missing
  coverage: '/^TOTAL\s+\d+\s+\d+\s+(\d+\%)$/'

security:
  stage: security
  script:
    - pip install bandit
    - bandit -r . -x venv

Пояснение: Ключевая деталь — coverage regex, который GitLab использует для отображения процента покрытия в UI. AI автоматически добавляет before_script для активации venv.

Промт 6: Docker-образ с Kaniko для безопасности без демона Docker

Цель: Собрать Docker-образ без привилегированного доступа (без Docker-in-Docker), используя Kaniko.
Запрос: "GitLab CI job: собрать Docker-образ из Dockerfile, используя Kaniko. Параметры: registry gitlab.example.com, образ my-app, тег $CI_COMMIT_SHORT_SHA. CACHE_REGISTRY для кэширования слоёв. Сохрани auth в GitLab CI variables DOCKER_CONFIG."
Результат:

build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  script:
    - /kaniko/executor
      --context $CI_PROJECT_DIR
      --dockerfile $CI_PROJECT_DIR/Dockerfile
      --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
      --cache=true
      --cache-ttl 24h
  variables:
    DOCKER_CONFIG: $CI_JOB_ID

Пояснение: Kaniko не требует Docker-демона, что безопаснее. Промт включает --cache=true — Kaniko кеширует слои в registry, экономя время сборки.

Промт 7: Параллельные джобы для микросеривсов с Dynamic Child Pipelines

Цель: Запускать тесты для каждого микросервиса параллельно с помощью child pipelines.
Запрос: "Создай GitLab CI конфиг с trigger для child pipeline. В родительском пайплайне загрузи список микросервисов из файла services.yml. Для каждого сервиса запусти child pipeline с переменной SERVICE_NAME. Child pipeline собирает и тестирует только свой сервис."
Результат:

# .gitlab-ci.yml (родитель)
stages:
  - triggers

trigger_job:
  stage: triggers
  trigger:
    include:
      - local: child-ci.yml
    strategy: depend
  parallel:
    matrix:
      - SERVICE_NAME:
        - auth-service
        - api-gateway
        - user-service

# child-ci.yml
image: alpine:latest

stages:
  - build
  - test

build-$SERVICE_NAME:
  stage: build
  script:
    - echo "Building $SERVICE_NAME"

test-$SERVICE_NAME:
  stage: test
  script:
    - echo "Testing $SERVICE_NAME"

Пояснение: Промт использует parallel:matrix для итерации по сервисам. Child pipeline изолирует окружение. На практике такой подход ускоряет общий пайплайн за счёт параллельного выполнения.

Промт 8: Deploy на Kubernetes с помощью kubectl через GitLab CI

Цель: Задеплоить приложение в Kubernetes кластер, используя переменные окружения для kubeconfig.
Запрос: "GitLab CI job для деплоя в K8s. Используй образ bitnami/kubectl. Стадии: deploy. Получи kubeconfig из переменной KUBECONFIG (base64 decode). Примени manifests из папки k8s/. Добавь approval gate (environment: production)."
Результат:

deploy-production:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - echo "$KUBECONFIG" | base64 -d > /tmp/kubeconfig
    - export KUBECONFIG=/tmp/kubeconfig
    - kubectl apply -f k8s/
    - kubectl rollout status deployment/app
  environment:
    name: production
    url: https://app.example.com
  when: manual
  only:
    - main

Пояснение: when: manual добавляет ручной триггер (approval). rollout status ждёт стабилизации деплоя. AI корректно обрабатывает base64-декодирование.

Промты для ArgoCD

ArgoCD — GitOps-оператор для Kubernetes. Промты помогают генерировать Application манифесты и настройки синхронизации.

Промт 9: Application для ArgoCD с синхронизацией из Git

Цель: Создать ресурс Application для деплоя сервиса из репозитория.
Запрос: "ArgoCD Application manifest для деплоя в namespace 'staging' из https://github.com/my-org/k8s-manifests.git, путь 'apps/backend', кластер 'https://kubernetes.default.svc'. Установи syncPolicy automated с prune и selfHeal. Добавь destination server и namespace."
Результат:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/k8s-manifests.git
    targetRevision: HEAD
    path: apps/backend
  destination:
    server: https://kubernetes.default.svc
    namespace: staging
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
      - CreateNamespace=true

Пояснение: Промт включает CreateNamespace=true — AI автоматически создаёт namespace, если его нет. prune удаляет ресурсы, которых нет в Git.

Промт 10: Kustomize-оверлеи для разных окружений

Цель: Сгенерировать Application, использующий Kustomize для production/staging overlays.
Запрос: "ArgoCD Application для приложения с Kustomize. Source — та же репа, path 'apps/frontend/overlays/production'. Настрой рекурсивный sync. Добавь health check на Ingress."
Результат:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: frontend-production
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/k8s-manifests.git
    targetRevision: HEAD
    path: apps/frontend/overlays/production
    kustomize:
      version: v5.4.0
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
    syncOptions:
      - Validate=true
  healthChecks:
    - check: "status.ingress[0].ready"
      timeout: 120s

Пояснение: Промт явно указывает healthChecks — эта секция опциональна, но AI может её добавить, если попросить. Kustomize-оверлей подтягивает базовые ресурсы и накладывает production-патчи.

Промт 11: App of Apps паттерн для управления множеством приложений

Цель: Создать главное Application, которое управляет другими Applications через App of Apps.
Запрос: "ArgoCD ApplicationSet с генератором git files для App of Apps. Читай файл apps.yaml в корне репозитория, для каждого элемента создавай Application с именем {{name}}. Template: source path '{{path}}', destination namespace '{{namespace}}', syncPolicy automated."
Результат:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: app-of-apps
spec:
  generators:
    - git:
        repoURL: https://github.com/my-org/k8s-manifests.git
        revision: HEAD
        files:
          - path: "apps.yaml"
  template:
    metadata:
      name: '{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/my-org/k8s-manifests.git
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{namespace}}'
      syncPolicy:
        automated: {}

Пример apps.yaml:

- name: backend
  path: apps/backend
  namespace: production
- name: frontend
  path: apps/frontend
  namespace: production

Пояснение: ApplicationSet — продвинутая фича ArgoCD. Промт создаёт шаблон, который масштабируется на любое количество приложений. Достаточно добавить запись в apps.yaml.

Промт 12: Продвинутая стратегия синхронизации с wave (Sync Waves)

Цель: Настроить порядок синхронизации: сначала ConfigMap, потом Deployment, потом Service.
Запрос: "Добавь sync waves в Application. ConfigMap — wave -5, Deployment — wave 0, Service — wave 5. Используй аннотацию argocd.argoproj.io/sync-wave. Напиши три ресурса (ConfigMap, Deployment, Service) с нужными аннотациями."
Результат:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  annotations:
    argocd.argoproj.io/sync-wave: "-5"
data:
  key: value
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: my-app:latest
---
apiVersion: v1
kind: Service
metadata:
  name: app-service
  annotations:
    argocd.argoproj.io/sync-wave: "5"
spec:
  ports:
    - port: 80

Пояснение: Sync Waves позволяют контролировать порядок применения ресурсов. ConfigMap создаётся первым, Deployment — после, Service — последним. Промт даёт готовый YAML с аннотациями.

Промт 13: Интеграция с GitLab CI: запуск sync по событию

Цель: Настроить вебхук или автоматический sync при изменении репозитория через CI.
Запрос: "GitLab CI job, который при деплое в production запускает ArgoCD sync через API. Используй curl c $ARGOCD_TOKEN и $ARGOCD_SERVER. Запрос POST /api/v1/applications/backend/sync."
Результат:

sync-argocd:
  stage: deploy
  image: curlimages/curl:latest
  script:
    - curl -X POST "$ARGOCD_SERVER/api/v1/applications/backend/sync" \
        -H "Authorization: Bearer $ARGOCD_TOKEN" \
        -H "Content-Type: application/json" \
        -d '{"prune": true, "dryRun": false, "strategy": { "hook": {} }}'
  only:
    - main

Пояснение: Промт использует strategy.hook для синхронизации с запуском пре- и пост-синк хуков. Токен хранится в CI variable. Это альтернатива вебхукам из ArgoCD.

Промт 14: Мониторинг и уведомления о статусе синхронизации

Цель: Настроить уведомления в Slack при неудачной синхронизации.
Запрос: "ArgoCD Notification template для Slack. Триггер: on-sync-failed. Сообщение: 'Application {{.app.name}} sync failed in {{.app.destination.namespace}}'. Канал '#ops'. Используй argocd-notifications helm chart."
Результат (часть конфигурации ConfigMap):

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  config.yaml: |
    triggers:
      - name: on-sync-failed
        description: "Application sync failed"
        when: app.status.sync.status == 'OutOfSync' and app.status.health.status == 'Degraded'
        send: [slack]
    templates:
      - name: slack
        title: "[ArgoCD] {{.app.metadata.name}} sync failed"
        body: |
          Application {{.app.metadata.name}} in {{.app.spec.destination.namespace}} sync failed.
          Sync status: {{.app.status.sync.status}}
          Health status: {{.app.status.health.status}}
    destinations:
      slack:
        webhook: "https://hooks.slack.com/services/xxx/yyy/zzz"

Пояснение: Промт генерирует не Application, а конфиг уведомлений. Это важная часть GitOps-практики — получать оповещения о сбоях. AI правильно использует when с двойным условием.

Промт 15: Ограничение ресурсов и RBAC для разных команд

Цель: Настроить ArgoCD Project с ограничениями на namespace и кластеры.
Запрос: "ArgoCD Project 'team-a' с sourceRepos: ['https://github.com/team-a/'], destination: кластер 'in-cluster', namespace 'team-a-'. Добавь clusterResourceWhitelist: только Namespace. Установи orphanedResources: warn."
Результат:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
spec:
  sourceRepos:
    - 'https://github.com/team-a/*'
  destinations:
    - namespace: 'team-a-*'
      server: https://kubernetes.default.svc
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
  orphanedResources:
    warn: true

Пояснение: Промт ограничивает команду только своими репозиториями и namespace. orphanedResources: warn уведомляет о ресурсах, не отслеживаемых ArgoCD. Это базовая security-практика.

Заключение

Эти 15 промтов — мой личный набор «швейцарского ножа» для быстрой настройки CI/CD в ежедневной работе. Они не идеальны: каждый требует доработки под конкретный проект. Но они экономят часы на начальной раскадровке. Пробуйте, адаптируйте, и не забывайте проверять сгенерированный код на синтаксис. А ещё лучше — добавьте эти промты в ваш персональный AI-инструмент как сниппеты. Если у вас есть любимый промт, которого нет в списке, напишите в комментариях — я обновлю подборку. Удачных пайплайнов!