Как вызвать azure devops построить конвейер на основе сообщения коммита?

Question

Я строю Azure проект Devops. проект имеет как пользовательский интерфейс, так и коды приложений Backend. Оба кода размещены как один проект в GitLab. Но для UI и Backend работают разные команды. Мне нужно настроить два конвейера сборки, один для изменений пользовательского интерфейса и один для внутренних изменений.

Мне нужно запустить конкретный c конвейер на основе сообщений фиксации. то есть; если изменение пользовательского интерфейса выполнено, то в сообщении о фиксации будет содержаться ключевое слово " UI_CHANGES ". Azure DevOps должен распознавать это и запускать конвейер сборки пользовательского интерфейса.

Когда я гуглил, я узнал, что Azure DevOps не поддерживает фильтрацию на основе фиксации сообщений для запуска нового конвейера сборки.

Могу ли я использовать здесь теги Git? Если да, пожалуйста, сообщите мне, как его использовать. Любые другие возможные идеи также приветствуются!

Заранее спасибо.

Answer 1

На мой взгляд, вам нужен какой-то "фильтр пути". Azure DevOps имеет встроенный «фильтр пути», но он работает только для репозиториев, размещенных на Azure Devops.

Мои предложения, что вы можете сделать в текущей ситуации.

• Переместите свой репозиторий в Azure DevOps Это лучшее решение, на мой взгляд, но оно не применимо, если вам по какой-то причине придется придерживаться GitLab

  • Pro: У вас есть репо и конвейеры в одном месте
  • Con: Вы должны переместить репо и установить новые членства и т.д. c.

• Build / Publi sh с GitLab У меня нет опыта работы с конвейерами в GitLab, поэтому я не могу сказать, является ли это жизнеспособным решением

  • Pro: у вас есть репозиторий и конвейеры в одном месте, и вам не нужно перемещать
  • Я не уверен, как сборка / публикация работает с GitLab (ни за, ни против)

• Отразите репозиторий GitLab на Azure DevOps Вы можете использовать это расширение * 10 38 * для постоянного зеркалирования репо из GitLab в Azure DevOps и сборки / publi sh со встроенным фильтром пути конвейера

  • Pro: вам не нужно перемещаться, но вы можете использовать конвейеры из Azure DevOps
  • Con: Вы зависите от расширения, которое «соединяет» только два независимых репо.

• Подключите репозиторий GitLab с помощью Azure DevOps и выполнения логической части в конвейере Я думаю, что это наименее благоприятное решение, потому что вы должны выполнять всю логическую работу вручную в своем конвейере. Тем не менее, если вы заинтересованы в этом решении Я рекомендую дополнительно взглянуть на это расширение . Но это не так удобно, как фильтр путей по умолчанию.

ОБНОВЛЕНИЕ Я только что посмотрел на это расширение глубже, и я не думаю, что оно подходит вашему необходимо. Простите за это. Тем не менее, вы можете просто подключиться к репозиторию GitLab без расширения. Просто создайте PAT для чтения ваших репозиториев и добавьте служебное соединение для "Other git" в Azure DevOps .
Как упоминалось ранее, вы можете сделать логи c того, что строить внутри вашего трубопровода (не выгодно).

Ура и удачи!

Answer 2

Вам не нужно запускать конвейер в соответствии с сообщением фиксации, вы можете создать два конвейера и в триггере определить, какие будут работать при использовании фильтров Path: