Версионирование артефактов сборки в Gradle используя git имена тегов, бранчей и коммитов

[@varnav]

переезд из Jenkins на Gitlab-CI — достойно отдельного поста кстати!

[@nulled]

На самом деле нету тут материала на отдельную статью. Уже думал на эту тему.

[@Hubbitus]

varnav, честно говоря, тут в общем всё просто, но зависит от ваших специфических нужд. На хабре уже есть неплохие стати на эту тему, например Введение в GitLab CI.
По моим впечатлениям, он просто потрясающий. А открытость его разработки заслуживает особого восхищения. Они очень быстро обычно реагируют на баги. Помню ездил на highload++ в этом году, просто к слову пожаловался в беседе что они не правят багу с раннером для приватного репозитория docker что я им ставил… Так они не только исправили в тчении ближайших пару дней, так ещё и написали мне об этом дополнительно.

Однако мне для полного счастья всё же не хватает некоторых вещей. Например для для того чтобы удобнее работать с контейнерами вроде: #25047, #25000.

Но это ж больше хотелки, понятно что они больше сосредоточены на энтерпрайзных вещах вроде kubernetes, автоскалирования в облаке…
А с точки зрения начать использовать — действительно просто по туториалу сконфигурить.
Если у вас есть какие-то конкретные вопросы, то буду рад помочь, а так чтобы на отдельную статью, просто и не знаю что писать…

[@varnav]

Мне просто казалось что они не взаимозаменяемы, т.к. сильно разные по сути.

[@Hubbitus]

На самом деле, с Jenkins 2.0, когда они у себя также внедрили концепцию пайплайнов (pipline), разрыв значительно уменьшился. На митапе в Яндексе в прошлом году, они очень активно рассказывали как это всем поможет. Теперь не обязательно все билды «накликивать мышкой». Раньше для меня это было просто бедой, хотя и можно было экспортировать конфигурацию в XML. Теперь можно нормально версионировать скажем с помощью того же GIT.
Однако остаётся проблема что всё-таки это отдельно от кода, от проекта. Версионируется отдельно, релиз-циклы как-то надо согласовывать. Тестировать отдельно…

Ну и опять же, gitlab и gitlab-ci имеют из коробки гораздо более плотную интеграцию. Тут вам прогресс билда, и просмотр лога, и артефакты сборки прямо на странице билда, и авторизация общая, тут же можно указать сколько хранить артефакты, чтобы место освободить, тут же и docker-registry свой предлагают (я правда не использую его, сторонним пользуемся. И к слову тут нет автоочистки образов, хотя обещают добавить по моей просьбе). Ну и много других приятных мелочей.

[@varnav]

Однако остаётся проблема что всё-таки это отдельно от кода, от проекта. Версионируется отдельно, релиз-циклы как-то надо согласовывать. Тестировать отдельно…

В смысле?

Ну и опять же, gitlab и gitlab-ci имеют из коробки гораздо более плотную интеграцию. Тут вам прогресс билда, и просмотр лога, и артефакты сборки прямо на странице билда… можно указать сколько хранить артефакты, чтобы место освободить

Это функции Jenkins-а из коробки.

[@Hubbitus]

Это не функции Jenkins никак, если у вас проект в другом месте. В лучшем случае, может быть плагин интеграции, который сможет решить часть проблем. Но в общем gitlab не так много хуков предлагает, чтобы сделать это так же удобным как с его CI. Если вам не предоставляется возможности рядом с коммитом отобразить статус билда из другой системы (исключительно для примера, с другими возможностями также) — то вы это из плагина не сделаете.

[@Deosis]

Если нужен тэг, можно попробовать использовать команду git describe, которая вернет строку вида Tag-Count-gHash

[@Hubbitus]

Конечно можно. И парсить вывод. А если бинарного git нет в PATH ещё поставить его или подтянуть зависимость. А потом прикритить логику парсинга имен бранчей, потом логику формирования версий. А потом добавить логику обработки dirty рабочей копии, а потом ввести чтение переменных окружения… А потом понять что этого кода в скрипте билда стало больше чем остального описания билда и вынести это в плагин градл. Ну или взять один из имеющихся.

[@furic]

Feature, not future. Исправьте пожалуйста

[@Hubbitus]

Спасибо, исправил