Блог

Мой monorepo — это структура как таковая, где подкаталоги являются либо «микросервисами», либо ресурсами:

 /app
  /admin
  /admin-v2
  /api
  /api-v2
  /client
  /k8s
  /postgres
  /scripts
  azure-pipelines.yaml
  skaffold.yaml
 

У меня есть одна часть головоломки. Я знаю, что следующая команда сообщит мне, на какие «микросервисы» повлияла фиксация, связанная с этим PR:

 $ git diff --name-only $COMMIT_ID | awk -F'/' 'NF!=1{print $1}' | sort -u
admin-v2
api-v2
client
postgres
 

Я знаю, что каждый этап в моем конвейере будет соответствовать одному из этих «микросервисов», и мне понадобится предыдущая команда на каждом этапе, чтобы увидеть, присутствует ли этот этап. Если это так, его необходимо запустить. Если нет, этап может быть проигнорирован.

Моя конечная цель — заставить разработчика нажать на удаленный с их недолговечной веткой, открыть PR для слияния в магистраль, когда PR открыт, он запускает конвейер CI для создания «микросервиса», запуска модульных и интеграционных тестов, только на «микросервисах», которые находятся в их PRвместо того, чтобы перестраивать все, каждый раз.

Хотел бы сделать это из одного azure-pipelines.yaml . Альтернативой было бы иметь по одному в каждом подкаталоге и отдельные конвейеры для каждого, что может вызвать проблемы.

Предложения о том, как это реализовать?

PR-триггер без перестройки, тестирования, повторного развертывания всех служб в конвейере в монорепо

Триггер PR — это не то же самое, что триггер CI в репозиториях Azure Git. Это потому , что:

В репозиториях Azure Git эта функциональность реализована с использованием политик ветвления. Чтобы включить проверку запросов на извлечение в репозиториях Azure Git, перейдите к политикам ветвей для нужной ветви и настройте политику проверки сборки для этой ветви. Для получения дополнительной информации см. раздел Настройка политик ветвей.

Итак, триггеры PR в YAML по-прежнему не поддерживаются в Azure DevOps, мы не могли использовать условие напрямую для сборки, тестирования, развертывания, например:

 condition: contains(variables['Build.SourceBranch'], 'refs/heads/staging')
 

Мы должны добавить задачу powershell в сборку, тестирование, развертывание, чтобы определить, какие «микросервисы» были затронуты фиксацией, связанной с PR, например:

 $editedFiles = git diff HEAD HEAD~ --name-only
echo "$($editedFiles.Length) files modified:"
$editedFiles | ForEach-Object {
   echo $_
    Switch -Wildcard ($_ ) {
        'app/admin-v2/*' { 
              # If the admin-v2 is updated, we need to generate the variable Enable_Admin-v2
              Write-Output "##vso[task.setvariable variable=Enable_Admin-v2]True" 
         }        
        'app/api-v2/*' { Write-Output "##vso[task.setvariable variable=api-v2]True"  }
        # The rest of your path filters
    }
}
 

Этот скрипт устанавливает переменные, на которые затем ссылаются в пользовательских условиях на следующем шаге конвейера сборки, тестирования и развертывания:

 and(succeeded(), eq(variables['Enable_Admin-v2'], 'True'))