Підключити хост коду
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 requests | ✓ | — | — |
| Шаблони опису 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. Див. Додати репозиторії до робочого простору.
Після інтенсивного використання все на якийсь час перестає працювати
Розділ із назвою «Після інтенсивного використання все на якийсь час перестає працювати»Це запобіжник на випадок обмеження частоти запитів. Коли хост коду повідомляє про досягнення основного ліміту, клієнт починає локально відхиляти подальші запити, без мережевого звернення, доки не спливе вікно, — тож шквал повторних спроб не може поглибити ліміт. Тимчасові збої повторюються з експоненційною затримкою.