Блог

У нас есть задание (развертывание в производство), которое мы обычно выбираем вручную после проверки этой сборки на промежуточном этапе. Однако очень редко у нас возникает проблема, которую мы случайно развернули, и мы хотим исправить как можно скорее. В этом случае мы запускаем тесты локально (намного быстрее) и помещаем [urgent-fix] в наше сообщение о фиксации, чтобы остановить выполнение тестов в CI (переходя сразу к сборке образа Docker и промежуточному развертыванию).

Что мы хотели бы сделать, так это то, что если мы поместим [urgent-fix] , это автоматически запустит производственное развертывание (обычно это when: manual шаг). Можем ли мы как-то этого добиться?

Похоже, вы можете использовать комбинацию синтаксиса only:variables и $CI_COMMIT_MESSAGE предопределенной переменной.

Грубая идея (непроверенная):

 .deploy_production: amp;deploy_production
  stage: deploy production
  script:
    - echo "I'm deploy production here"
  tags:
    - some special tag

deploy::manual:
  << *deploy_production
  when: manual
  allow_failure: false

deploy:urgent_fix:
  << *deploy_production
  only:
    variables:
      - $CI_COMMIT_MESSAGE =~/[urgent-fix]/
  

Начиная с GitLab версии 12.3 (~ сентябрь 2019), GitLab поставляется с «Гибкими правилами для конфигурации сборки CI». Функция предназначена для замены only/except функциональности и полностью документирована здесь.

С помощью rules: теперь вы можете полностью влиять на when: поведение вашего задания в зависимости от различных условий (в отличие от only/except: того, что заставляло вас создавать отдельные задания для ситуаций, подобных описанной в OP; см. Принятый ответ).

Например, вы можете сделать:

 deploy:
  rules:
    - if: '$CI_COMMIT_TITLE =~ /urgent-fix/'
      when: on_success
    - when: manual # default fallback
  script:
    - sh deploy.sh
  

Следует подчеркнуть то, что в приведенном выше примере я использовал $CI_COMMIT_TITLE вместо $CI_COMMIT_MESSAGE (см. Документы gitlab), чтобы избежать повторного появления строки «срочное исправление» в сообщении о фиксации, автоматически собранном в ходе git merge , которое затем случайно запустило бы задание повторно.

Отказ от ответственности: Пожалуйста, имейте в виду, что новая rules: функция вступает в конфликт с only/except: и, следовательно, требует от вас удаления only/except: вхождений. Также, пожалуйста, обратите внимание, что rules: это следует использовать только в сочетании с workflow: (читайте документы), чтобы избежать запуска нежелательных «отсоединенных» конвейеров.