Конечно можно. И парсить вывод. А если бинарного git нет в PATH ещё поставить его или подтянуть зависимость. А потом прикритить логику парсинга имен бранчей, потом логику формирования версий. А потом добавить логику обработки dirty рабочей копии, а потом ввести чтение переменных окружения… А потом понять что этого кода в скрипте билда стало больше чем остального описания билда и вынести это в плагин градл. Ну или взять один из имеющихся.
Это не функции Jenkins никак, если у вас проект в другом месте. В лучшем случае, может быть плагин интеграции, который сможет решить часть проблем. Но в общем gitlab не так много хуков предлагает, чтобы сделать это так же удобным как с его CI. Если вам не предоставляется возможности рядом с коммитом отобразить статус билда из другой системы (исключительно для примера, с другими возможностями также) — то вы это из плагина не сделаете.
Ну на самом деле для Fedora Server давно обсуждается как минимум цикл в 6 релизов: https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle и подобные разговоры у нас в рассылке всплывали с регулярным постоянством в прошлом. Везде есть свои плюсы и минусы и у всего есть своя цена.
Разумеется вы можете придумать дальше нужную вам схему, в том числе порт. Кстати в Linux нет проблемы использовать: в имени директории, соответственно вполне можно создавать и традиционный путь вроде root@server.xxx:2224. У меня ж пример, всё что может понадобится не предусмотреть, хотя замечание хорошее.
А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.
На самом деле, с Jenkins 2.0, когда они у себя также внедрили концепцию пайплайнов (pipline), разрыв значительно уменьшился. На митапе в Яндексе в прошлом году, они очень активно рассказывали как это всем поможет. Теперь не обязательно все билды «накликивать мышкой». Раньше для меня это было просто бедой, хотя и можно было экспортировать конфигурацию в XML. Теперь можно нормально версионировать скажем с помощью того же GIT.
Однако остаётся проблема что всё-таки это отдельно от кода, от проекта. Версионируется отдельно, релиз-циклы как-то надо согласовывать. Тестировать отдельно…
Ну и опять же, gitlab и gitlab-ci имеют из коробки гораздо более плотную интеграцию. Тут вам прогресс билда, и просмотр лога, и артефакты сборки прямо на странице билда, и авторизация общая, тут же можно указать сколько хранить артефакты, чтобы место освободить, тут же и docker-registry свой предлагают (я правда не использую его, сторонним пользуемся. И к слову тут нет автоочистки образов, хотя обещают добавить по моей просьбе). Ну и много других приятных мелочей.
Простите, не совсем понимаю что вы имели ввиду. Что лучше не монтировать автоматически потому что можно удалить не тот файл? Ну так и если по SSH если будете заходить — не исключена ошибка ввода не того имени хоста. А чем отличается уровень возможности ошибки при ввода хоста в строке подключения от строки файлового пути — не очень понятно.
varnav, честно говоря, тут в общем всё просто, но зависит от ваших специфических нужд. На хабре уже есть неплохие стати на эту тему, например Введение в GitLab CI.
По моим впечатлениям, он просто потрясающий. А открытость его разработки заслуживает особого восхищения. Они очень быстро обычно реагируют на баги. Помню ездил на highload++ в этом году, просто к слову пожаловался в беседе что они не правят багу с раннером для приватного репозитория docker что я им ставил… Так они не только исправили в тчении ближайших пару дней, так ещё и написали мне об этом дополнительно.
Однако мне для полного счастья всё же не хватает некоторых вещей. Например для для того чтобы удобнее работать с контейнерами вроде: #25047, #25000.
Но это ж больше хотелки, понятно что они больше сосредоточены на энтерпрайзных вещах вроде kubernetes, автоскалирования в облаке…
А с точки зрения начать использовать — действительно просто по туториалу сконфигурить.
Если у вас есть какие-то конкретные вопросы, то буду рад помочь, а так чтобы на отдельную статью, просто и не знаю что писать…
Полагаю вы не вполне поняли для чего afuse и autofs.
x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.
Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!
Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
Ну тут действительно проблема в том что нужно отслеживать всё дерево, включая удалённые файловые системы. А с ними вообще будет беда по скорости.
И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.
Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
Autofs тоже хорошая штука, согласен. Я его тоже использовал.
Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
Из серьёзных минусов:
значительно сложнее в настройке. Работает на древнем automount
при этом далеко не тривиален в дебаге, если что-то не так работает как хочется. Вот например я ставил пару багов на него: bz#961312, bz#961299.
Последнюю закрыли не разбираясь, по таймауту :( Если посмотреть в багзилле кроме моих, то их тоже очень не мало, что тоже немного отталкивает.
Нет, по умолчанию ssh достаточно! Есть конечно возможность его ограничить отдельным списком команд дополнительно, но мы сейчас не будем рассматривать эти случаи. А вообще работает даже с shared хостингами на ура.
Кстати, вместо использования sshfs вы вполне также можете использовать автомаонтирование nfs с помощью afuse! Потребуются незначительные модификации скрипта-хелпера. Однако nfs требует экспорта файловых систем, вся прелесть sshfs в том что вы можете так монтировать любой хост, на который у вас есть ssh доступ, без каких-то дополнительных подготовок на нём.
Если хост недоступен, разумеется вы не сможете читать его. Но, во-первых, это просто sshfs, поведение будет в точности такое же. К afuse это не имеет отношения.
Но если вернуться к вопросу как оно будет себя вести, то при переходе в эту директорию команда просто подвиснет. В моём примере используется опция "-o reconnect", соответственно sshfs будет постоянно пытаться переконнектиться, и сделает это как только хост станет доступен, то есть вы увидите просто задержку. Если же хост стал полностью недоступен, вы можете просто убить соответствующий sshs процесс с помощью kill. Ну и отмонтировать конкретную директорию: fusermount -u somehost
Однако полагаю это всё же уже оффтопик.
А вот на пользователя директории для коннекта никто не ориентируется. По умолчанию берётся тот, кто прописан для хоста в ~/.ssh/config. А если нужно указать другого, то для этого случая я и описал в статье что можно использовать нотацию user@host.
Однако остаётся проблема что всё-таки это отдельно от кода, от проекта. Версионируется отдельно, релиз-циклы как-то надо согласовывать. Тестировать отдельно…
Ну и опять же, gitlab и gitlab-ci имеют из коробки гораздо более плотную интеграцию. Тут вам прогресс билда, и просмотр лога, и артефакты сборки прямо на странице билда, и авторизация общая, тут же можно указать сколько хранить артефакты, чтобы место освободить, тут же и docker-registry свой предлагают (я правда не использую его, сторонним пользуемся. И к слову тут нет автоочистки образов, хотя обещают добавить по моей просьбе). Ну и много других приятных мелочей.
По моим впечатлениям, он просто потрясающий. А открытость его разработки заслуживает особого восхищения. Они очень быстро обычно реагируют на баги. Помню ездил на highload++ в этом году, просто к слову пожаловался в беседе что они не правят багу с раннером для приватного репозитория docker что я им ставил… Так они не только исправили в тчении ближайших пару дней, так ещё и написали мне об этом дополнительно.
Однако мне для полного счастья всё же не хватает некоторых вещей. Например для для того чтобы удобнее работать с контейнерами вроде: #25047, #25000.
Но это ж больше хотелки, понятно что они больше сосредоточены на энтерпрайзных вещах вроде kubernetes, автоскалирования в облаке…
А с точки зрения начать использовать — действительно просто по туториалу сконфигурить.
Если у вас есть какие-то конкретные вопросы, то буду рад помочь, а так чтобы на отдельную статью, просто и не знаю что писать…
x-systemd.automount не делает ничего более, как формирует automount unit for filesystem.
Это удобно для сетевых систем, прописанных в /etc/fstab, чтобы они сразу не монтировались, а только по мере доступа к ним.
Но т.к. юнит формируется по строке из fstab, то вы должны будете прописать все ваши сотни серверов для возможности монтирования по sshfs! Это именно то, от чего мы хотели избавиться!
Мы так или иначе прописываем одну строку для моунтпоинта автомонтирования (/mnt/remote в моём примере). Будет ли она работать с x-systemd.automount я не знаю, но смысл всё равно отсутствует — в сущности это ж псевдо система, и пока вы не обратититесь внутрь этой системы, да ещё и к директории с нужным именем, ничего удалённого здесь всё равно не монтируется.
И наверное теоретически FUSE можно было бы реализовать, но как вы сами заметили, скорость будет вряд ли приемлемой.
Для архивов в общем вполне не плохо справляются все среды, чтобы зайти в них, и Gnome и KDE. В консоли тот же Midnight прекрасно «заходит» в архивы.
Да, это не вполне удобно, потому что решения разные, симлинки не сделаешь, нет интероперабельности… Но с другой стороны, в большинстве случаев такой доступ всё равно очень медленный и нужен лишь чтобы «быстренько взглянуть что там», ну или поглядеть пару небольших файлов вроде README. А с этим указанные средства вполне справляются. Если вам понадобилось содержимое архива полностью, то полное его извлечение будет на порядок быстрее с помощью последовательного чтения и использования родного архиватора.
Из важных плюсов — умеет отмонтировать файловые системы по настроенному таймауту и это удобно.
Из серьёзных минусов:
Но если вернуться к вопросу как оно будет себя вести, то при переходе в эту директорию команда просто подвиснет. В моём примере используется опция "-o reconnect", соответственно sshfs будет постоянно пытаться переконнектиться, и сделает это как только хост станет доступен, то есть вы увидите просто задержку. Если же хост стал полностью недоступен, вы можете просто убить соответствующий sshs процесс с помощью kill. Ну и отмонтировать конкретную директорию: fusermount -u somehost