Подключить хост кода
Control Center работает с тремя хостами кода, которые в приложении называются forges: GitHub, GitLab и Bitbucket Cloud. Ни один из них не используется по умолчанию. Подключите один — и всё работает; подключите несколько — и одно рабочее пространство сможет одновременно содержать репозитории всех трёх.
Хост кода — это свойство каждого репозитория: он считывается из его remote origin при регистрации. Вы никогда не выбираете его вручную, и здесь нет настройки уровня рабочего пространства, которую можно было бы задать неправильно.
Подключить хост кода
Заголовок раздела «Подключить хост кода»- Откройте Настройки → Рабочее пространство → Профиль и идентичность (
/settings/workspace/profile). - Найдите карточку Хостинг кода. В ней перечислены все поддерживаемые хосты кода — подключённые и нет.
- Нажмите Войти через …, если строка это предлагает, либо Добавить токен и вставьте токен.
Войти появляется для хоста кода, для которого на вашем сервере зарегистрировано приложение, — сегодня это GitHub, через device flow (см. Создать GitHub App). Во всех остальных случаях используется вставленный токен: это честный вариант взаимодействия, а не кнопка, которая не может довести дело до конца.
В любом случае учётные данные принадлежат вам и хранятся на сервере с привязкой к вашему идентификатору пользователя: токен не сохраняется на машине, в которую вы его ввели, все устройства, с которых вы входите, используют один и тот же токен, и ни один другой участник не может его прочитать. Он вступает в силу при следующем запросе — перезапускать ничего не нужно, а отключение немедленно прекращает его отправку.
Каждая строка сообщает, откуда взялись её учётные данные, — ведь в этом и разница между «мой токен не работает» и «отвечает другой токен»:
| Подпись | Значение |
|---|---|
Вы вошли как octocat |
Используются ваши собственные учётные данные |
Вы вошли как octocat · через приложение этого сервера |
Отвечает идентичность приложения сервера — вы не входили в систему |
Вы вошли как octocat · из окружения |
Отвечает переменная окружения сервера, а не ваши учётные данные |
Не подключено |
У вас нет учётных данных для этого хоста кода |
Какой токен нужен каждому хосту кода
Заголовок раздела «Какой токен нужен каждому хосту кода»| Хост кода | Токен | Где его создать |
|---|---|---|
| GitHub | Классический: repo и read:org. Fine-grained: Contents + Pull requests (read/write), Checks + Actions (read) |
github.com → Settings → Developer settings → Tokens |
| GitLab | Персональный токен доступа с областью действия api |
gitlab.com → User settings → Access tokens |
| Bitbucket | Токен Atlassian API и адрес электронной почты вашего аккаунта | id.atlassian.com → Security → API tokens |
Bitbucket аутентифицируется, используя адрес электронной почты аккаунта как имя пользователя и токен как пароль. Задайте BITBUCKET_EMAIL в окружении сервера, чтобы он знал, с каким адресом электронной почты сопоставлять токен.
Или используйте окружение
Заголовок раздела «Или используйте окружение»Для headless-установки или установки в CI сервер читает следующие переменные:
- GitHub —
GITHUB_TOKEN, затемGH_TOKEN - GitLab —
GITLAB_TOKEN, затемCI_JOB_TOKEN - Bitbucket —
BITBUCKET_API_TOKEN, затемBITBUCKET_TOKEN(вместе сBITBUCKET_EMAIL)
Это учётные данные сервера, а не ваши, и это различие принципиально: запрос, сделанный от вашего имени, использует ваши учётные данные и ничего больше, поэтому окружение никогда не подменяет вас незаметно. Работа, за которой не стоит человек, — вебхуки, опрос PR, синхронизация тикетов — сначала обращается к идентичности приложения сервера, затем к учётным данным владельца сервера, а затем к окружению. Порядок фиксирован, поэтому «я вошёл, а ничего не изменилось» никогда не является поддерживаемым исходом.
На каждом хосте кода вы — другой человек
Заголовок раздела «На каждом хосте кода вы — другой человек»Один и тот же человек — octocat на GitHub и совсем кто-то другой на GitLab. Control Center определяет вашу идентичность для каждого хоста кода и использует подходящую для каждого репозитория — именно поэтому в смешанном рабочем пространстве корректно работают «нужно моё ревью», «создано мной» и «вы это одобрили».
Если идентичность для хоста кода не определена, его репозитории ничего не добавляют во «Входящие», а не совпадают со всем подряд. «Входящие» сообщают об этом, а не утверждают, что вы всё просмотрели.
Одни «Входящие» для всех хостов кода
Заголовок раздела «Одни «Входящие» для всех хостов кода»«Входящие» и очередь PR расходятся по всем хостам кода, представленным в рабочем пространстве, и сливают результаты в один поток — pull request из GitHub и pull request из Bitbucket стоят рядом, упорядоченные по времени, а не сгруппированные по поставщику.
Сбои изолированы. Хост кода, который недоступен, ограничен по частоте запросов или не подключён, ничего не добавляет и не затрагивает остальные; он никогда не опустошает «Входящие» целиком. Его собственные репозитории продолжают показывать последнее известное состояние, пока он не восстановится.
Что умеет каждый хост кода
Заголовок раздела «Что умеет каждый хост кода»Каждый хост кода поддерживает основной цикл: показывать список и открывать pull requests, читать диффы, комментировать построчно и на верхнем уровне, проводить ревью, мержить и закрывать. Помимо этого они действительно различаются, и Control Center скрывает то, чего хост кода не умеет, вместо того чтобы показывать элемент управления, который молча не сработает.
| Возможность | GitHub | GitLab | Bitbucket |
|---|---|---|---|
| Пакетные (отложенные) ревью | ✓ | ✓ | — |
| Запрос изменений | ✓ | ✓ | ✓ |
| Синхронизация состояния «просмотрено» по файлам | ✓ | — | — |
| Реакции эмодзи | ✓ | ✓ | — |
| Ревьюеры из команды или группы | ✓ | ✓ | — |
| Предложенные рецензенты | ✓ | — | ✓ |
| Результаты CI в PR | ✓ | ✓ | ✓ |
| Просмотр шагов и логов задачи CI | ✓ | ✓ | — |
| Стек pull request | ✓ | — | — |
| Шаблоны описания PR | ✓ | ✓ | — |
| Опрос уведомлений | ✓ | — | — |
| Подробные профили пользователей | ✓ | ✓ | — |
| Серверная ссылка head для PR | ✓ | ✓ | — |
Там, где возможности не хватает, функциональность честно деградирует:
- Состояние просмотра по-прежнему работает, но только на том устройстве, где вы его отметили.
- Пакетные ревью в Bitbucket публикуются комментарий за комментарием, поэтому ревьюеры видят, как они приходят по отдельности, а не все сразу.
- Отсутствие ссылки head для PR в Bitbucket означает, что при переключении на pull request его исходная ветка забирается по имени, а это перестаёт работать, как только ветка удалена.
Терминология
Заголовок раздела «Терминология»GitLab называет pull request merge request. Control Center во всей своей модели говорит «pull request» и использует собственный термин каждого хоста кода там, где речь идёт именно о нём.
Устранение неполадок
Заголовок раздела «Устранение неполадок»Список PR пуст и сообщает, что хост кода не подключён
Заголовок раздела «Список PR пуст и сообщает, что хост кода не подключён»У вас нет учётных данных для этого хоста кода. Войдите или вставьте токен в разделе Настройки → Рабочее пространство → Профиль и идентичность → Хостинг кода. Репозитории других хостов кода не затрагиваются.
Я подключил хост кода, но его репозитории по-прежнему ничего не показывают
Заголовок раздела «Я подключил хост кода, но его репозитории по-прежнему ничего не показывают»Проверьте подпись в строке. Если там указано «через приложение этого сервера» или «из окружения», отвечают не те учётные данные, которых вы ожидали: для всего, что запрашиваете вы, побеждают ваши собственные учётные данные, поэтому если строка говорит иначе, ваши не сохранились.
Репозиторий не регистрируется
Заголовок раздела «Репозиторий не регистрируется»Для регистрации нужны все три условия: путь находится внутри рабочего дерева git, у него есть remote origin, и этот remote указывает на github.com, gitlab.com или bitbucket.org. См. Добавить репозитории в рабочее пространство.
После интенсивного использования всё на время перестаёт работать
Заголовок раздела «После интенсивного использования всё на время перестаёт работать»Это автоматический выключатель при превышении лимита запросов. Когда хост кода сообщает о достижении основного лимита, клиент начинает локально отклонять дальнейшие запросы без сетевого обращения, пока окно не истечёт, — поэтому шквал повторных попыток не может усугубить лимит. Временные сбои повторяются с экспоненциальной задержкой.