DB
получаешь тег, и внутри джобы определяешь, какой ветке он принадлежит. не уверен, что это можно реализовать на уровне триггера
this
Size: a a a
2020 August 26
E
я этот функционал сунул в отдельную trigger джобу
k
крч есть такая тема как ScriptTrigger
можно делать poll с груви/баш скриптом
наверное это ваш выход
можно делать poll с груви/баш скриптом
наверное это ваш выход
с такким же успехом на баше можно сразу и написать
E
kbks
с такким же успехом на баше можно сразу и написать
ну других вариантов особо и нет
M
всякие multi-branch pipeline'ы и organization folder'ы умеют делать branch indexing (например каждую минуту), и их можно настроить на сборку бранчей, change request'ов и тэгов
> branch indexing (например каждую минуту)
а потом упираешься в rate limit :(
а потом упираешься в rate limit :(
k
всякие multi-branch pipeline'ы и organization folder'ы умеют делать branch indexing (например каждую минуту), и их можно настроить на сборку бранчей, change request'ов и тэгов
да, сейчас такк другие собираются. но для этой джобы не сильно вариант
AB
> branch indexing (например каждую минуту)
а потом упираешься в rate limit :(
а потом упираешься в rate limit :(
rate limit 5000 в час, мы пока не упираемся)
M
rate limit 5000 в час, мы пока не упираемся)
Это в BitBucket? Просто мы очень быстро упёрлись с ~10-ю проектами и в итоге иногда собирались огромные очереди на сборку/сканирование
AB
Это в BitBucket? Просто мы очень быстро упёрлись с ~10-ю проектами и в итоге иногда собирались огромные очереди на сборку/сканирование
не, я ж написал, мы так для гитхаба делаем. Значит для битбакета не вариант :(
M
не, я ж написал, мы так для гитхаба делаем. Значит для битбакета не вариант :(
а, окей
Н
а 2.235 прикольный, ушел курить ченджлог
DS
kbks
так мне нужны теги (читай коммиты) только из мастера.
ветка это указатель на коммит, который ездит вверх по коммитам, тег это указатель на коммит, который всегда смотрит на конкретный коммит. Нет связи между веткой и тегом, но ты можешь попробовать отловить связи коммитов. Например если коммит на который указывает ветка, потомок коммита на который указывает тег, вероятно тег был создан из этой ветки. Но это не факт, так как такой коммит может быть потомком для нескольких веток.
Тогда точно на какой ветке был создан коммит узнать не получится, но можно узнать список кандидатов.
Тогда точно на какой ветке был создан коммит узнать не получится, но можно узнать список кандидатов.
DB
а и не надо. появился коммит в ветке - запускаем процесс
это если трекать только одну ветку. если несколько - будут проблемы
это если трекать только одну ветку. если несколько - будут проблемы
DS
а и не надо. появился коммит в ветке - запускаем процесс
это если трекать только одну ветку. если несколько - будут проблемы
это если трекать только одну ветку. если несколько - будут проблемы
в таком случае задача не имеет смысла (определить из какой ветки сделан тег), в случае одной ветки, это будет конкретная ветка =)
DB
так, задача как раз - отлавливать теги в конкретной ветке
DB
и игнорировать прочие
DS
так, задача как раз - отлавливать теги в конкретной ветке
а я думал другое.
Я думал у него на каждый тег, jenkins запускает отдельную джобу (multibranch pipeline)
И там он делает грубо говоря git clone , git checkout tag-name
И надо в этой задаче понять, из какой ветки был сделан коммит
Я думал у него на каждый тег, jenkins запускает отдельную джобу (multibranch pipeline)
И там он делает грубо говоря git clone , git checkout tag-name
И надо в этой задаче понять, из какой ветки был сделан коммит
DB
ну, реализация будет именно такой. ловить все теги, проверять, присутствуют ли они в конкретной ветке, и если да - запускать билд
DS
ну, реализация будет именно такой. ловить все теги, проверять, присутствуют ли они в конкретной ветке, и если да - запускать билд
вот, и тут может быть засада. напрмер пометили в ветке master коммит A тегом, затем в эту ветку закомити B, и из него сделали еще одну ветку branch1.
В итоге мы определим, что тег был сделан как бы в двух ветках master и branch1. Хотя это не проблема, главное что master в этом списке присутсвтует
В итоге мы определим, что тег был сделан как бы в двух ветках master и branch1. Хотя это не проблема, главное что master в этом списке присутсвтует
DB
я про то и толкую. главное, что в нужной ветке тэг есть. где он ещё присутствует - дело десятое.
но это при условии, что проверяем всего одну ветку
но это при условии, что проверяем всего одну ветку