мы на GitLab.  сегодня мы всей командой активно фиксим баги перед деплоем и пушим в одну ветку. перестали отображатся новые коммиты на сайте в той ветке. это перегруз какой-то? не сталкивались?

возможно ветки устарели у челиков

Всем привет!
Ситуация: используем GitHub для разработки большой системы, тесты запускаются на Jenkins, один прогон стоит много, ибо в тестах запускается где-то полтысячи виртуальных машин в облаках. Иногда запускать тесты при push-е с открытым PR не имеет смысла: это долгострой, review которого открыт, чтобы мнения собирать; другой вариант: разработчик получает комментарии в PR, за это время master уезжает, поэтому делается rebase, push, проходит время, потом человек адресует комментарии в review, делается push с нужными изменениями (два push-а делаются, чтобы можно было посмотреть через GitHub "чистые изменения" и не разгребать rebase).
Вопрос: как наиболее удобно пропускать определённые шаги на CI? В идеале выглядеть должно примерно так: git push -f --skip-tests (да, нужен alias в shell). Можно добавлять что-то в commit message, потом парсить на стороне Jenkins, но это требует модификации commit-ов. Можно dummy commit делать, но будет лишний commit, который будет мешаться при просмотре PR на GItHub. Можно добавлять метку к PR на GitHub и читать её в Jenkins, но это надо заходить на GitHub перед push-ем или ставить консольный клиент GitHub и авторизовываться в нём каждому разработчику, а их больше сотни... (склоняюсь к этому варианту).
Может есть какое-то простое решение, о котором я не подумал?

Для публичных CI нормальной практикой является дописывание к коммитам [skip ci]

Ну да, я читал, что недавно GitHub actions в это научился. Печально, если нет более простого способа. Гипотетически никто же не мешает git вместе с commits передавать какие-то метаданные на удалённый сервер, а на стороне сервера уже решать, как обработать их, например, пропустить CI...

У Jenkins есть rest api..

Проблема такая же, как и решением PR labels + GitHub CLI: надо аутентифицироваться каждому разработчику. Но таки да, это, наверное, прямее сразу в Jenkins ходить и из него метку добавлять в PR. Видимо, остановлюсь на этом варианте. Спасибо, я что-то действительно забыл довольно очевидный вариант!

здравствуйте пацаны и пацанессы, я вот отправил PR в гитхабе, и вот такой прикол: The base branch restricts merging to authorized users.

что и как это работает, можете объяснить?

это я должен что-то настроить, или те кто принимает?

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

А не хотите отключить автоматический запуск CI, и вместо этого попросить девелоперов его запускать руками? Комментариями в PR, или ещё как-то.

Кажется, в базовом бранче ограничили список тех, кто может туда пушнуть.

Бо́льшая часть push-ей всё-таки требует запуска CI, так что, наверное, нет, так будет неудобно.

Всё-таки добавлять ещё один инструмент (я про клиент GitHub или Jenkins) для каждого разработчика не хочется(

Придумал такой костыль: добавлять пустой commit с message "disable ci", который будет находиться Jenkins-ом, drop-аться в rebase, force push-иться обратно на GitHub, после чего CI будет останавливается с выставленной меткой PR "untested" на GitHub. Если надо опять обратно включить CI, то можно добавить commit с "enable ci". Надо написать скрипт, который чистит rebase-ом попарные "disable-enable" и положить его в pre-commit, который мы используем. Плюсы: на стороне разработчика не нужно никаких новых инструментов, никаких существующих commits трогать не надо, PR diff будет чистый, PR будет помечен, в master не попадёт лишних commits. Минусы: выглядит как магия, force push автоматом — звучит фигово (хотя это всё тестируется, плюс вроде бы ничего сложного делать не надо).

Покритикуйте, пожалуйста)

Очень сложная система, много где может сломаться, сложно будет отлаживать.

Есть такое(
Отвлечённый вопрос: я не очень знаком с внутренностями git и интересно: есть ли фундаментальная проблема в том чтобы передавать вместе с push какое-то свободное тестовое содержимое и обрабатывать его на удалённом сервере?

Идеологическая проблема тут. Обычно Гит просто обменивается объектами и синхронизует состояние хранилища в нескольких местах. Очень странно поверх этого натягивается RPC.

Понятно, спасибо.

Возможно ли это реализовать с помощью -o/--push-option как тут? Или это не то? (Просто интересно)

А я не вижу там ничего про push-option.