GitHub CLI 1.0

Теперь вайтишники git и github будут путать ещё больше

нам предлагают подключить левую репу и поставить через sudo микрософтовский код не глядючи?
а кто-нибудь эти сырцы изучал? сколько там телеметрии?

эти сырцы изучал? сколько там телеметрии?

Вы серьёзно?!!! Из сорцов всё может быть вырезано, а бинарники собраны с телеметрией… Не только код нужно изучать, а целиком все сборки.

Исходники тут:
https://github.com/cli/cli

Что интересно, они используют trunk вместо master.
https://github.com/cli/cli/commit/9d11cedd181f5576ea8182883ecc3f6cd4162222

Зачем изучать бинарники, когда можно самому собрать или пользоваться сборками от доверенных людей?

Если я правильно всё понял, и это поделие – надстройка над «гитом», то не нужно. Git и так нормально работает, а тут один Фортран знает, что туда эти «брахманы» понапихивали.

Вы неправильно поняли.

Это набор команд для Гитхаб.

У гит уже есть командная строка.

Грустно смотреть на весь этот цирк с «корректными» терминами. Особенно, блин, в контексте гита где мастер никогда не исподьзовался в паре со слейвом.

Надеюсь до сжигания либерахами неугодных в печах дело не дойдёт в итоге.

Net::GitHub::V3 наше всё!

В арче уже собран из сорцов: https://github.com/archlinux/svntogit-community/blob/packages/github-cli/trunk/PKGBUILD

Никак левых реп.

а кто-нибудь эти сырцы изучал? сколько там телеметрии?

А сколько обычно нужно?

Было бы неплохо иметь что-то такое для GitLab{, CI}.

А что они обо мне узнают, чего еще не знают через браузер?

Сколько порно лежит в хомяке, и как выглядит мой кот?

Согласен, не очень понимаю напрягов с телеметрией, если телефоны слушают разговоры, а банки и операторы периодически сливают информацию.

Что интересно, они используют trunk вместо master.

Да неинтересно это, честно говоря. Менять технические термины из-за каких-то мифических социальных проблем - крайне глупая затея.

Было бы неплохо иметь что-то такое для GitLab{, CI}

Туда сначала надо нормальный API завезти.

Казалось бы?

Туда сначала надо нормальный API завезти.

В проектах десятки лет используется trunk. по моему даже чаще чем мастер.

Ещё до воспламенения СЖВ

И до появления git

Было бы неплохо иметь что-то такое для GitLab{, CI}.

Не, нужно не это.

Нужно gitforge-cli с разными вариантами бекенда: GitHub, GitLab, BitBucket, Gerrit, Pagure,…

В идеале нужен стандарт и совместимость API с ним.

Мыслишь широко и утопично. :)

Так-то да, но это всё примерно там же, где федерация issues и пулл-реквестов, т. е. даже не на горизонте. (Внесите ДеВолта.)

А вообще конкретно я имел в виду не столько пулл-реквесты, сколько например CLI для GitLab CI, потому что прокликивать одни и те же кнопки порядком надоело. А учитывая, насколько разнится устройство CI/CD-движков в различных forge, универсальный интерфейс ты к ним запилить заведомо не сможешь. Ну или сможешь, но придётся этот интерфейс сводить к общему минимуму, что также сведёт к общему минимуму его практическую полезность.

А что за кнопки ты прокликиваешь в CI?

Он же сейчас везде as a code, один раз сконфигурил и работает, голосует на pull request.

Единственное что ретриггер может быть нужен.

В идеале конечно и на CI-yaml надо стандарт сделать, а то он сейчас у всех разный, но это уже другая история.

Единственное что ретриггер может быть нужен.

Вот эти, например.

Переменные на уровне веб-интерфейса иногда приходится прописывать. Смотреть логи и результаты джобов и пайплайнов. Артефактами и проектами жонглировать. И т. п.

Переменные на уровне веб-интерфейса иногда приходится прописывать.

Это условно-одноразовая акция. Ты не на каждый пулл-реквест же это делаешь.

Смотреть логи и результаты джобов и пайплайнов.

Ну это все как раз одинаковое. То есть логи и арефакты посмотреть можно у всех, просто по разным путям.

Всякие жонглирования проектами - это уже 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

https://gitlab.com/bichon-project/bichon

Я не думаю что CLI-only - это разумное требование. Надо использовать сильные стороны каждого интерфейса там где это имеет смысл.

Вот создавать через браузер pull-request после того как в cli сказал git push - это бесит. А видеть GUI-дашборд со статусом всяких сложных пайплайнов - это абсолютно нормально.

А для нормального управления проектами надо просто выкинуть github и gitlab и использовать геррит, в котором проектами можно управлять(в том числе создавать и настраивать права) через те же ямлы.

А как это там работает?

https://docs.opendev.org/opendev/system-config/latest/jeepyb.html

В OpenStack написали отдельную утилитку которая через API управляет всем.

Вообще OpenStack Infra реально решили проблему и CLI, и пайплайнов, и Git Forge, и DevInfraAsACode. Не решили только проблему с маркетингом этого добра. И это безумно печально.

Для этой задачи нужен Infra as a code а не cli.

А кто-то в этом мире умеет 100% Ia(a)C?

Я не умею. Всегда найдётся задача (или часть задачи), которую либо тупо выгоднее, либо возможно только сделать руками и задокументировать.

Для сложной структуры, которую случайный человек с ходу не понимает, нужен UI который сначала объясняет что к чему и только потом уже предлагает тебе что-то сделать.

А такой задачи не стоит ни перед сабжем, ни перед тем, что я с тобой обсуждаю. Гипотетический GitLab CLI — это для тех, кто уже отлично представляет себе, как устроен гитлаб, и хочет делать дела быстрее.

В OpenStack написали отдельную утилитку которая через API управляет всем.

Вообще OpenStack Infra реально решили проблему и CLI, и пайплайнов, и Git Forge, и DevInfraAsACode. Не решили только проблему с маркетингом этого добра. И это безумно печально.

Ну это ты с козырей заходишь.

В проектах десятки лет используется trunk. по моему даже чаще чем мастер.

Да и ладно, кто же против-то? Мне вот всё равно, как называть основную ветку; я не могу понять, почему кто-то оскорбляется из-за конкретных названий :-)

Так чем Trunk плох?

Почему это вызвало мнение что меняются технические термины?

Ведь trunk и branch это части tree вашего репо.

Я не умею. Всегда найдётся задача (или часть задачи), которую либо тупо выгоднее, либо возможно только сделать руками и задокументировать.

Так я о том что 100% и не надо.

А такой задачи не стоит ни перед сабжем, ни перед тем, что я с тобой обсуждаю. Гипотетический GitLab CLI — это для тех, кто уже отлично представляет себе, как устроен гитлаб, и хочет делать дела быстрее.

Я подозреваю что когда у тебя запутанный набор пайплайнов, быстрее таки будет либо через код в нормальной IDE, либо через визуализацию.

Потому что CLI по типу kubernetes, например, вызывает только лишь стойкое желание написать к нему другой cli. Пока там нужный под найдешь, уже в gui три раза бы натыкал.

Но в общем я бы посмотрела наверное на дизайн такого cli. Может я ошибаюсь.

Ну это ты с козырей заходишь.

Я вообще морально готовлюсь статью писать с рабочим названием Demystifying Gerrit or Why Greg Kroah Hartman was wrong.

Сейчас вот ещё немного в твиттерах поплачусь на эту тему и достигну нужного состояния души…

Так чем Trunk плох?

Ничем. Кто говорил, что транк плох?

Кто говорил, что транк плох?

Я не понял вашего?

я не могу понять, почему кто-то оскорбляется из-за конкретных названий :-)