Получить текущий путь к тому, что вызвало конвейер (YAML)
Я пытался отследить/отладить большинство переменных здесь https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml, но ни одна из них не показывает, что запустило конвейер.
Если MyDir — это дерево каталогов с n подкаталогами, содержащими файлы, я хочу знать, какой файл на самом деле вызвал мой конвейер (путь к файлу)
trigger:
paths:
include:
- MyDir/*
Я использую Git и экспериментировал с Git log, но
git diff HEAD HEAD~ --name-only, похоже, дает неплохие результаты.
Любые идеи?
ОБНОВИТЬ В итоге я сделал скрипт Bash, который перебирает файлы в текущем коммите. Они мне понадобились на более позднем этапе
Я не знаком конкретно с Azure DevOps, но многие из этих систем могут иметь несколько триггеров, и если они не скажут вам, какие триггеры вызванный им запускать, единственный способ, которым вы могли бы узнать, — это «волшебство». ": вам нужно знать, что было в состоянии "до", что произошло и какие у них могли быть триггеры, и повторить всю логику в них. Поэтому обычно неразумно настраивать любую систему, которая заботится о том, Зачем она была запущена, если только сама система не сообщит вам об этом прямо.
Ответы 1
But if two commits happens at the same time I still don't know what actually triggered my pipeline.
Непонятно, как вы реализовали два коммита одновременно.
Вы можете использовать следующую задачу с командой Git, чтобы вывести список файлов изменений:
- powershell: |
## get the changed files
$files=$(git diff HEAD HEAD~ --name-only)
$temp=$files -split ' '
$count=$temp.Length
echo "Total changed $count files"
$files | ForEach-Object {
echo $_
}
Если вы включите CI, каждый коммит будет запускать отдельную сборку, тогда мы будем получать измененное имя файла и путь в каждой сборке.
Если вы отправляете фиксацию локально, и каждая фиксация содержит несколько измененных файлов, мы можем использовать цикл ForEach для вывода списка и пути имен измененных файлов:
Лео, сделай именно это, но в задаче Bash. Я думаю, это не проблема, если два члена команды совершают/объединяются одновременно.
Хм. Вы можете использовать API, чтобы найти последнюю сборку конвейера для текущей ветки (или, в противном случае, последнюю сборку вашей основной ветки). Оттуда вы можете получить коммит, на котором выполнялась предыдущая сборка. На этом этапе вы можете рассчитать изменения между фиксациями (а не просто использовать
HEAD~1) и выяснить, какие файлы являются соответствующими изменениями. Там могут быть лучшие способы сделать это.