Вы говорите, что у вас не может быть запланированного триггера и триггера CI, но это не так. Пожалуйста, проверьте документацию здесь .
Если вы хотите запустить свой конвейер, используя только запланированные триггеры, вы должны отключить PR и триггеры непрерывной интеграции, указав pr: none и trigger: нет в вашем файле YAML. Если вы используете Azure Repos Git, сборки PR настроены с использованием политики ветвления и должны быть отключены там.
Таким образом, у вас есть два варианта:
- Храните все это в одном файле YAML и проверьте, какая ветка или как сборка запускалась при условии развертывания на надлежащий сервер.
- У вас может быть две сборки, но во избежание повторения вы извлекаете общие вещи в шаблон и повторно используете их. в определении сборки (так что на самом деле в этом случае у вас будет 3 файла yaml).
Несколько примеров:
- вы хотите выполнить задание только для мастера ветвь:
jobs:
- job: A
steps:
- script: echo hello
- job: B
dependsOn: A
condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/master'))
steps:
- script: echo this only runs for master
- вы хотите извлечь общие шаги и повторно использовать их в определении сборки
Общие шаги:
# File: simple-param.yml
parameters:
- name: yesNo # name of the parameter; required
type: boolean # data type of the parameter; required
default: false
steps:
- script: echo ${{ parameters.yesNo }}
Определение сборки:
# File: azure-pipelines.yml
trigger:
- master
extends:
template: simple-param.yml
parameters:
yesNo: false # set to a non-boolean value to have the build fail
Вы можете прочитать о шаблонах в документации или проверить пример в моем блоге .
Если хотите Для того, чтобы classi c выпускные конвейеры, вам нужно определить два релизных конвейера. Инес с триггером для указания c ветви.
Подводя итог: вы можете делать то, что вы хотите, и у вас есть несколько способов достижения это. Моя рекомендация - использовать отдельные конвейеры с шаблоном, так как это делает определение сборки более чистым, чем условие, чтобы проверить, для какой ветви или как была запущена сборка.
В этой переменной Build.Reason вы можете проверить, как была запущена ваша ветка:
- Вручную: пользователь вручную поставил в очередь сборку.
- IndividualCI: непрерывная интеграция (CI), инициированная Git pu sh или регистрацией TFV C.
- BatchedCI: непрерывная интеграция (CI), запускаемая Git pu sh или регистрация TFV C, и пакетные изменения были выбраны.
- Расписание: запуск по расписанию. ValidateShelveset: пользователь вручную поставил в очередь сборку указанного c TFV C полочного набора.
- CheckInShelveset: закрытый триггер регистрации.
- PullRequest: сборка была инициирована политикой ветвления Git, которая требует сборки.
- BuildCompletion: сборка была запущена другой сборкой.
- ResourceTrigger: сборка была инициирована триггером ресурса.
Затем вы можете использовать эту переменную в условии. Для получения дополнительной информации, пожалуйста, go здесь .
Закрывая это, имейте в виду, что существует специальный вид job, называемый deployment для развертываний. Пожалуйста, рассмотрите возможность использования этого, если вы собираетесь развернуть свое приложение с использованием конвейера yaml.
Для вашего дополнительного вопроса: вы можете переопределить настройки для вашей сборки. Я имею в виду, вы можете иметь триггер для мастера и только мастер-ветку Но все же вы можете запустить сборку для других веток (например, ветки разработки) (например, вручную). Что случилось потом? Сборка будет работать для новой определенной ветки. В конце это определение сборки и запуск автоматического управления выполнением сборки c.