Если я правильно всё понял, и это поделие – надстройка над «гитом», то не нужно. Git и так нормально работает, а тут один Фортран знает, что туда эти «брахманы» понапихивали.
Так-то да, но это всё примерно там же, где федерация issues и пулл-реквестов, т. е. даже не на горизонте. (Внесите ДеВолта.)
А вообще конкретно я имел в виду не столько пулл-реквесты, сколько например CLI для GitLab CI, потому что прокликивать одни и те же кнопки порядком надоело. А учитывая, насколько разнится устройство CI/CD-движков в различных forge, универсальный интерфейс ты к ним запилить заведомо не сможешь. Ну или сможешь, но придётся этот интерфейс сводить к общему минимуму, что также сведёт к общему минимуму его практическую полезность.
Переменные на уровне веб-интерфейса иногда приходится прописывать. Смотреть логи и результаты джобов и пайплайнов. Артефактами и проектами жонглировать. И т. п.
Переменные на уровне веб-интерфейса иногда приходится прописывать.
Это условно-одноразовая акция. Ты не на каждый пулл-реквест же это делаешь.
Смотреть логи и результаты джобов и пайплайнов.
Ну это все как раз одинаковое. То есть логи и арефакты посмотреть можно у всех, просто по разным путям.
Всякие жонглирования проектами - это уже feature creep, я бы ограничила scope одним существующим проектом.
А для нормального управления проектами надо просто выкинуть github и gitlab и использовать геррит, в котором проектами можно управлять(в том числе создавать и настраивать права) через те же ямлы.
Это условно-одноразовая акция. Ты не на каждый пулл-реквест же это делаешь.
Ты предполагаешь, что я пилю код. А я пилю пайплайны.
Ну это все как раз одинаковое. То есть логи и арефакты посмотреть можно у всех, просто по разным путям.
Артефакты для ветки, артефакты для джобы, артефакты для пайплайна, история последних, upstream jobs, downstream jobs, ретриггер такой, ретриггер сякой, ретриггер для рефа, ретриггер с переменными… Очень сильно сомневаюсь, что условный универсальный квадратно-гнездовой CI/CD CLI будет всё это уметь эквивалентно нативному интерфейсу.
А для нормального управления проектами надо просто выкинуть github и gitlab и использовать геррит, в котором проектами можно управлять(в том числе создавать и настраивать права) через те же ямлы.
А как это там работает? Куда эти ямлы в геррите выгружаются? В отдельные эндпоинты в API? Или есть «мета-репозиторий», в котором лежит ямл, который конфигурирует все остальные репозитории?
Ты предполагаешь, что я пилю код. А я пилю пайплайны.
Для этой задачи нужен Infra as a code а не cli.
Очень сильно сомневаюсь, что условный универсальный квадратно-гнездовой CI/CD CLI будет всё это уметь эквивалентно нативному интерфейсу.
Ты считаешь CLI тебя в этом случае спасет?
CLI нужен для базовых частых стандартных действий. Для сложной структуры, которую случайный человек с ходу не понимает, нужен UI который сначала объясняет что к чему и только потом уже предлагает тебе что-то сделать.
На базе CLI такое рисовать - это получится не cli, а TUI, как например Bichon
Я не думаю что CLI-only - это разумное требование. Надо использовать сильные стороны каждого интерфейса там где это имеет смысл.
Вот создавать через браузер pull-request после того как в cli сказал git push - это бесит. А видеть GUI-дашборд со статусом всяких сложных пайплайнов - это абсолютно нормально.
А для нормального управления проектами надо просто выкинуть github и gitlab и использовать геррит, в котором проектами можно управлять(в том числе создавать и настраивать права) через те же ямлы.
В OpenStack написали отдельную утилитку которая через API управляет всем.
Вообще OpenStack Infra реально решили проблему и CLI, и пайплайнов, и Git Forge, и DevInfraAsACode. Не решили только проблему с маркетингом этого добра. И это безумно печально.
Я не умею. Всегда найдётся задача (или часть задачи), которую либо тупо выгоднее, либо возможно только сделать руками и задокументировать.
Для сложной структуры, которую случайный человек с ходу не понимает, нужен UI который сначала объясняет что к чему и только потом уже предлагает тебе что-то сделать.
А такой задачи не стоит ни перед сабжем, ни перед тем, что я с тобой обсуждаю. Гипотетический GitLab CLI — это для тех, кто уже отлично представляет себе, как устроен гитлаб, и хочет делать дела быстрее.
В OpenStack написали отдельную утилитку которая через API управляет всем.
Вообще OpenStack Infra реально решили проблему и CLI, и пайплайнов, и Git Forge, и DevInfraAsACode. Не решили только проблему с маркетингом этого добра. И это безумно печально.
В проектах десятки лет используется trunk. по моему даже чаще чем мастер.
Да и ладно, кто же против-то? Мне вот всё равно, как называть основную ветку; я не могу понять, почему кто-то оскорбляется из-за конкретных названий :-)
Я не умею. Всегда найдётся задача (или часть задачи), которую либо тупо выгоднее, либо возможно только сделать руками и задокументировать.
Так я о том что 100% и не надо.
А такой задачи не стоит ни перед сабжем, ни перед тем, что я с тобой обсуждаю. Гипотетический GitLab CLI — это для тех, кто уже отлично представляет себе, как устроен гитлаб, и хочет делать дела быстрее.
Я подозреваю что когда у тебя запутанный набор пайплайнов, быстрее таки будет либо через код в нормальной IDE, либо через визуализацию.
Потому что CLI по типу kubernetes, например, вызывает только лишь стойкое желание написать к нему другой cli. Пока там нужный под найдешь, уже в gui три раза бы натыкал.
Но в общем я бы посмотрела наверное на дизайн такого cli. Может я ошибаюсь.
Ну это ты с козырей заходишь.
Я вообще морально готовлюсь статью писать с рабочим названием Demystifying Gerrit or Why Greg Kroah Hartman was wrong.
Сейчас вот ещё немного в твиттерах поплачусь на эту тему и достигну нужного состояния души…