Как запустить Job в ручном режиме в GitLab CI

Запуск Job в ручном режиме в GitLab CI

ГитЛаб предоставляет несколько способов для ручного управления выполнением задач в pipeline. Это критически важно для контролируемых развертываний, особенно в production окружении.

Основной способ: Директива when: manual

stages:
  - build
  - deploy

build:
  stage: build
  script:
    - npm install
    - npm run build

deploy_production:
  stage: deploy
  script:
    - npm run deploy
  when: manual
  only:
    - main

После этой конфигурации job появится в UI pipeline с кнопкой "Play" для ручного запуска.

Типы manual jobs

when: manual — job не запускается автоматически, требует ручного запуска из UI.

when: on_failure — job запускается только если предыдущий stage завершился с ошибкой.

when: on_success — job запускается только если предыдущий stage успешен (по умолчанию).

when: always — job запускается всегда, независимо от статуса.

Условный запуск с rules

deploy_production:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
    - when: never

Здесь job запустится вручную только для main ветки, для остальных не появится.

Запуск через GitLab API

Если нужно запустить job программно:

# Получить ID pipeline
PIPELINE_ID=$(curl -s "https://gitlab.com/api/v4/projects/PROJECT_ID/pipelines" \
  --header "PRIVATE-TOKEN: $GITLAB_TOKEN" | jq '.[0].id')

# Запустить конкретный job
curl -X POST "https://gitlab.com/api/v4/projects/PROJECT_ID/pipelines/$PIPELINE_ID/jobs/JOB_ID/play" \
  --header "PRIVATE-TOKEN: $GITLAB_TOKEN"

Практический пример: Контролируемое развертывание

stages:
  - build
  - test
  - deploy_staging
  - deploy_production

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE

test:
  stage: test
  image: $DOCKER_IMAGE
  script:
    - npm run test

deploy_staging:
  stage: deploy_staging
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - develop

deploy_production:
  stage: deploy_production
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - main

Требование approval перед запуском

Для дополнительной безопасности можно требовать approval:

deploy_production:
  stage: deploy
  script:
    - ./deploy.sh
  when: manual
  protected: true  # Только maintainers могут запустить
  only:
    - main

Pipeline permissions

Для контроля кто может запускать manual jobs:

• Developer — не может запускать protected jobs
• Maintainer — может запускать все jobs
• Owner — имеет полные права

Взаимодействие с UI

1. Перейти в Projects → Pipelines
2. Выбрать нужный pipeline
3. Найти job с иконкой "Play" (manual job)
4. Нажать кнопку запуска
5. Результаты доступны в логах job'а

Best Practices

• Защищать production deployments — использовать when: manual для critial окружений
• Требовать approval — для особенно важных операций
• Ограничивать доступ — использовать protected: true
• Логировать операции — все manual запуски записываются в GitLab audit logs
• Использовать переменные — для передачи параметров в manual job

В моей практике я широко использую manual jobs для staged deployments: сначала на staging без ограничений, потом на production с approval требованием. Это позволяет быстро реагировать на проблемы и иметь контроль над изменениями в production.