Сценарий 3. Разработчики: добавить и убрать

Этот сценарий требует чуть больше внимания, чем два предыдущих, и вот почему: список участников описывает не изменения, а полное состояние. Кто в списке — у того есть доступ. Кого нет — у того доступ отберут.

Это одно предложение, и оно объясняет всё поведение ниже.

Три состояния: объявлен, не перечислен, убран везде

#Добавить человека

Два шага, и первый пропускают чаще всего.

Первое: убедитесь, что человек есть в people.yaml. Если нет — добавьте:

[email protected]:
  name: Имя Фамилия
  accounts:
    gitlab: existing_handle    # если аккаунт уже есть — иначе не пишите этот блок

Блок accounts говорит «возьми вот этот существующий аккаунт». Без него сервис ищет человека по почте и создаёт аккаунт, только если совпадений нет, а пароль не задаёт — GitLab сам отправит письмо для входа.

Второе: добавьте в проект.

members:
  - person: [email protected]
    role: owner
  - person: [email protected]   # добавили
    role: developer

Роли: guest, reporter, developer, maintainer, owner. Обычному разработчику нужен developer.

Если человеку нужен другой уровень на одном конкретном репозитории, это выражается так:

  - person: [email protected]
    role: developer
    overrides:
      acme-infra: maintainer

#Убрать человека

Уберите строку из members. Через несколько минут доступ будет отобран.

Если человек уходит из компании и его нужно убрать везде, уберите его из всех файлов проектов. Тогда аккаунт будет заблокирован, а не удалён.

Разница существенная. Блокировка обратима: вернули строку — аккаунт разблокировался, история коммитов, merge request'ы и упоминания на месте. Удаление необратимо и ломает ссылки. Сервис намеренно умеет только первое.

#Главная ошибка, и она дорогая

Список участников должен перечислять всех, кто есть, а не только того, кого вы добавляете.

Это уже случалось. Декларация, в которой автор указал только себя, запланировала снятие доступа у пяти участников живого проекта: двух работающих разработчиков и служебного аккаунта, потеря которого сломала бы чтение секретов всей платформы, а не одного проекта.

Служба вела себя правильно. Неполной была декларация.

Поэтому: прежде чем править список, посмотрите, кто в проекте есть сейчас, и перенесите всех. Предпросмотр покажет отзывы до мержа — читайте этот список, он существует ровно для этого случая.

#Что сервис не тронет

Доступ, унаследованный от родительской группы. Про такой сервис сообщит и оставит как есть: выдача живёт не здесь, значит и решение не здесь.

Администраторов платформы. Отдельная защита, потому что снятие доступа у администратора обычно означает ошибку в декларации, а не намерение.

#Небольшое, но полезное

Доступ к секретам проекта следует из членства, а не из административных прав. Человек, который администрирует платформу, но не указан в проекте, секреты этого проекта прочитать не сможет — и это задумано. Если кому-то нужно работать с секретами проекта, его нужно добавить в участники, а не выдать ему прав побольше.