У меня есть два решения в соответствующей папке, например.
SolutionA \ SolutionsA.sln
SolutionB \ SolutionB.sln
Для каждого решения настроена сборка с закрытой регистрацией; то есть два определения сборки GatedSolutionA и GatedSolutionB.
Теперь ситуация такова, что если я фиксирую изменения в обеих папках вместе, TFS показывает диалоговое окно для выбора сборки (раскрывающееся с GatedSolutionA, GatedSolutionB) для запуска с набором изменений. В моем наборе изменений есть критические изменения в решении B и неразрывные изменения в решении A. т.е. Build GatedSolutionB завершится ошибкой, но GatedSolutionA пройдет.
Когда я выбираю GatedSolutionA для построения с моим набором изменений, TFS регистрирует его, что, в свою очередь, оставляет решение B в нерабочем состоянии и цель закрытой регистрации не выполняется для решения B.
Если я изменяю триггер на CI для определений сборки, TFS ставит в очередь обе сборки.
Я ищу такое же поведение, т.е. все сборки Gated ставятся в очередь, и если одна из них не работает, набор изменений должен быть отклонен.
Примечание : я не хочу создавать одно определение сборки для обеих решения. Кроме того, я знаю, что мы можем избежать этой проблемы, создав два отдельных набора изменений, но обычно это происходит, когда разработчики не знают, что у них есть файлы, которые проверяются для решения, отличного от того, над которым они работают.
Поскольку TFS и Azure DevOps начали использовать GIT и запрос Pull - с помощью политик ветвления (в основной ветке) можно добавить более одной проверки сборки, например для изменений в пути SolutionA \ *
, BuildA можно настроить для постановки в очередь и проверки, и аналогично для изменений в пути SolutionB \ *
BuildB можно настроить для постановки в очередь и проверки, и, следовательно, для фиксации, имеющей изменения в обоих путях, обе сборки будут помещены в очередь для проверки. Подождите, пока использование GIT того стоило.
Политики филиалов: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation
Примечание: документация не обновляется для отображения фильтра пути, , и дефект возникает на github здесь https://github.com/MicrosoftDocs/vsts-docs/issues/3235 . Таким образом, фильтр доступен в Azure DevOps и на сервере.