Как проходит изменение

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

#Два способа отредактировать, один результат

Через браузер. Откройте catalog.geekstudio.kg/onboarding. Там есть редактор: вставляете декларацию, нажимаете предпросмотр, видите, что получится, и создаёте merge request кнопкой.

Руками. Клонируете gs-onboarding-state, правите файл, открываете merge request как обычно.

Разницы в результате нет. Браузер удобнее для первого раза, потому что показывает предпросмотр до того, как что-то создано. Руками удобнее, когда правка большая или когда вы уже понимаете, что делаете.

#Предпросмотр показывает, у кого отберут доступ

Это самая полезная вещь во всём процессе, и про неё чаще всего не знают.

Когда вы просите создать merge request, сервис отвечает не только «готово». Он возвращает список людей, которые потеряют доступ, если это смержить. Вы видите его до мержа, а не узнаёте по жалобе в чате через день.

Список появляется потому, что декларация описывает не «кого добавить», а кто должен иметь доступ. Кто не перечислен — тот доступ теряет. Про это подробнее в разделе про разработчиков, но помнить стоит с самого начала: список участников всегда полный, а не список изменений.

#Проверка перед мержем

Merge request проходит проверку, и проверка запускает тот же код, который потом будет исполнять службу. Не похожий, не отдельный линтер — тот же.

Из этого следует практическая вещь: если проверка прошла, декларация не может быть отвергнута позже. Вы не окажетесь в ситуации, когда merge request зелёный, а через пять минут в логах, которые вам не видны, служба говорит «не понимаю, что от меня хотят».

Если проверка не прошла, она называет, что именно не так — неизвестная почта, окружение, у которого кластер совпадает с соседним, сервис с запрещённым именем. Читайте сообщение целиком, оно написано для человека.

#Мерж делает человек

Смержить может тот, у кого есть право Maintainer на репозитории. Это не формальность: репозиторий управляет доступами всей платформы, и правка в нём — та же категория, что правка прав в облаке.

Если у вас нет такого права, это нормально. Откройте merge request и попросите посмотреть. Ваша часть работы на этом закончена корректно.

#Что происходит дальше

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

Если через десять минут ничего не появилось, это не «надо подождать ещё» — это повод посмотреть состояние.

#Где смотреть состояние

На catalog.geekstudio.kg/onboarding есть список проектов. У каждого видно, что уже сделано, что в работе, и что служба делать отказалась — с причиной.

Последнее важнее первого. Служба намеренно не делает некоторые вещи: не удаляет то, что вы убрали из описания, не создаёт репозиторий, которого нет. В таких случаях она не молчит и не притворяется, что всё хорошо, а пишет причину. Если ожидаемое не появилось, ответ, скорее всего, уже написан на этой странице.