TFS 2015, проблема с рабочим потоком Git и Jenkins

Question

Я пытаюсь создать новый рабочий поток. Мы используем TFS 2015 по предпосылке, поддерживаемой Git SCM. Тем не менее, я также хотел бы использовать Jenkins для сборки и развертывания. Мы строим .NET/mono Java & Java для android, nodejs и несколько других бит. Кроме того, автоматическое развертывание докеров из Jenkins. Поэтому, хотя новые сборки TFS выглядят лучше, я не хочу попробовать их прямо сейчас.

Мои проблемы касаются запросов на загрузку TFS и обзоров кода. Разработчики не могут подчиняться мастеру, у меня установлены политики филиалов, поэтому они должны представить запрос на перенос, который включает в себя перенаправление ветви на удаленный. Однако я не могу установить политику «требуемой сборки», поскольку, хотя я связал Jenkins, он позволяет мне выбирать сборки TFS как часть политики ветвления.

Таким образом, я связал Дженкинса с TFS с помощью функции сервисных крючков, и я могу начать сборку TFS таким образом, но я не думаю, что это помогает мне, так как она должна контролировать конкретную ветку. Поэтому вместо этого я просто опросил git от Дженкинса и построил против всех ветвей в репо, кроме мастера.

Что бы я хотел сделать, это заставить разработчика направить свою ветку на удаленный компьютер, создать Jenkins (я получил это далеко), а затем как-то опубликовать отчет о сборке или ссылку на него обратно в TFS, поэтому когда другие разработчики приступают к просмотру кода с использованием интерфейса TFS, он может перейти и просмотреть отчет о сборке. (это бит, где я застрял)

Как только это будет выполнено, и слияние будет выполнено, другие сборки для выполнения развертываний и т. д. могут работать против главной ветви. Его только эта ссылка обратно в TFS, с которой я борюсь, кто-нибудь еще получил ответ

У кого-нибудь есть решение? Я попытался добавить url к результатам сборки в примечания git, используя плагин git publish, но TFS, похоже, не отображает это нигде. Я подумал о создании сборки TFS, чтобы просто назвать работу Jenkins, но она немного взломана. Есть ли способ лучше?

Answer 1

Я решил это в конце. То, что я сделал, - это заставить Jenkins добавить еще одну фиксацию к запросу pull, причем комментарий в коммите является ссылкой на отчет сборки Jenkins. Мне также пришлось изменить задание Дженкинса, чтобы игнорировать коммиты пользователя Jenkins, чтобы предотвратить бесконечный цикл сборки.

Теперь, когда отправляется запрос на вытягивание, Дженкинс выбирает это, строит его и создает дополнительную фиксацию. Как рецензент, я получаю электронное письмо, предупреждающее меня, что был запрос на тяну. Я нажимаю на ссылку, чтобы пойти и посмотреть, и когда я перейду к фиксации, я вижу ссылку на отчет сборки Jenkins.

Это не идеальный вариант, но он работает. Это, безусловно, лучшее решение, чем отказ, потому что TFS не имеет этой функции.

Answer 2

Согласно вашему описанию, вы хотите вызвать Jenkins из TFS и опубликовать результат сборки Jenkins обратно в TFS.

Как сервисные крючки позволяют выполнять задачи для других служб, когда события происходят в ваших проектах tfs. Но TFS только предоставляет отчет сборки для сборки с определением сборки. На стороне TFS нет такой функции, которая возвращает результат сборки Jenkins обратно в TFS.