Code-hosting integrations¶

Weblate integrates with code-hosting sites in several separate places: repository access, incoming notifications, and pushing translations back. The exact setup depends on whether you use Hosted Weblate or run your own Weblate instance, and on whether Weblate should push directly or create pull or merge requests.

이 페이지를 공급자 중심 체크리스트로 사용하세요. 각 설정 페이지는 설정 문법의 표준 참고 문서로 유지됩니다.

설정 개요¶

Weblate가 저장소에 접근할 수 있게 권한을 부여합니다.
- For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow. The App gives Hosted Weblate repository access without inviting the hosted weblate user.
- For other Hosted Weblate repositories, and for direct SSH pushes outside the GitHub App workflow, add the hosted weblate user where it is available, see 호스팅 Weblate에서 저장소 접근.
- For self-hosted Weblate, create a dedicated code-hosting user and grant access using Weblate’s SSH key or an HTTPS token, see Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Weblate가 저장소를 복제할 수 있도록 소스 코드 저장소 를 구성하십시오.
푸시 직후 Weblate가 변경사항을 가져오도록 수신 알림을 구성하세요. 저장소 웹훅 또는 앱은 일치하는 Weblate 훅 URL을 가리켜야 하며, 프로젝트에는 후크 활성화 가 활성화되어 있어야 합니다.
Weblate가 번역을 어떻게 되돌려 푸시할지 결정하세요:
- 직접 푸시하려면 Git 또는 Mercurial 과 저장소 푸시 URL 를 사용하세요.
- 풀 리퀘스트나 병합 요청을 만들려면 GitHub 또는 GitLab 같은 공급자별 VCS 백엔드를 사용하세요. 이러한 백엔드는 Weblate 설정에 API 자격 증명이 필요합니다.
지원되는 경우 포크를 사용하는 대신 Weblate가 업스트림 저장소의 브랜치로 푸시해야 한다면 필요에 따라 푸시 브랜치 를 지정하세요.

Weblate에서 변경사항 푸시¶

각 번역 구성 요소에는 푸시 URL을 설정할 수 있으며(저장소 푸시 URL 참조), 이 경우 Weblate는 변경 사항을 원격 저장소로 푸시할 수 있습니다. 또한 Weblate는 커밋할 때마다 변경 사항을 자동으로 푸시하도록 구성할 수 있습니다. 이 기능은 기본적으로 활성화되어 있으며, 자세한 내용은 커밋 시 푸시 을 참조하십시오.

변경사항이 자동으로 푸시되지 않게 하려면 저장소 유지관리 에서 수동으로 푸시하거나 API를 통해 wlc push 를 사용할 수 있습니다.

Weblate를 통한 직접 푸시를 원하지 않는 경우, GitHub 풀 리퀘스트, GitLab 병합 요청, Gitea 풀 리퀘스트, Pagure 병합 요청, Azure DevOps 풀 리퀘스트 또는 Gerrit 리뷰 요청 리뷰를 지원합니다. 구성요소 설정 에서 버전 관리 시스템 로 GitHub, GitLab, Gitea, Gerrit, Azure DevOps 또는 Pagure 를 선택하여 이를 활성화할 수 있습니다.

전체적으로 Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center, Bitbucket Cloud에서 다음 옵션을 사용할 수 있습니다:

원하는 설정	버전 관리 시스템	저장소 푸시 URL	푸시 브랜치
푸시 없음	Git	비어 있음	비어 있음
직접 푸시	Git	SSH URL	비어 있음
다른 브랜치로 푸시	Git	SSH URL	브랜치 이름
푸시 없음	Mercurial	비어 있음	비어 있음
직접 푸시	Mercurial	SSH URL	비어 있음
포크에서 GitHub 풀 리퀘스트	GitHub 풀 리퀘스트	비어 있음	비어 있음
브랜치에서 GitHub 풀 리퀘스트	GitHub 풀 리퀘스트	SSH URL [1]	브랜치 이름
포크에서 GitLab 병합 요청	GitLab 병합 요청	비어 있음	비어 있음
브랜치에서 GitLab 병합 요청	GitLab 병합 요청	SSH URL [1]	브랜치 이름
포크에서 Gitea 병합 요청	Gitea 풀 리퀘스트	비어 있음	비어 있음
브랜치에서 Gitea 병합 요청	Gitea 풀 리퀘스트	SSH URL [1]	브랜치 이름
포크에서 Pagure 병합 요청	Pagure 병합 요청	비어 있음	비어 있음
브랜치에서 Pagure 병합 요청	Pagure 병합 요청	SSH URL [1]	브랜치 이름
포크에서 Azure DevOps 풀 리퀘스트	Azure DevOps 풀 리퀘스트	비어 있음	비어 있음
브랜치에서 Azure DevOps 풀 리퀘스트	Azure DevOps 풀 리퀘스트	SSH URL [1]	브랜치 이름
Gerrit 리뷰	Gerrit 리뷰 요청	SSH URL	대상 브랜치 이름(선택 사항)
포크에서 Bitbucket Data Center 풀 리퀘스트	Bitbucket Data Center 풀 리퀘스트	비어 있음	비어 있음
브랜치에서 Bitbucket Data Center 풀 리퀘스트	Bitbucket Data Center 풀 리퀘스트	SSH URL [1]	브랜치 이름
포크에서 Bitbucket Cloud 풀 리퀘스트	Bitbucket Cloud 풀 리퀘스트	비어 있음	비어 있음
브랜치에서 Bitbucket Cloud 풀 리퀘스트	Bitbucket Cloud 풀 리퀘스트	SSH URL [1]	브랜치 이름

GitHub¶

GitHub 저장소 접근¶

Hosted Weblate GitHub App¶

On Hosted Weblate, the recommended setup is to connect the Hosted Weblate app from the Weblate workspace where your project lives. Use the Connect GitHub account flow, install the App on the GitHub user or organization that owns your repositories, grant it access to the repositories you want to translate, and import components from the connected GitHub account.

The App-backed workflow uses GitHub installation access tokens for cloning, pushing translation branches, creating pull requests, and receiving incoming notifications. You do not need to invite the Hosted Weblate weblate GitHub user or configure a separate repository webhook for components imported this way.

Use the Hosted Weblate weblate GitHub user only when you intentionally configure direct SSH pushes outside the GitHub App workflow, see 호스팅 Weblate에서 저장소 접근.

개인 액세스 토큰을 사용한 HTTPS¶

단일 비공개 저장소의 경우 제공자가 HTTPS를 통한 Git을 지원한다면 접근 토큰을 사용한 HTTPS 접근이 보통 가장 간단한 설정입니다. 소스 코드 저장소 에 제공자가 요구하는 사용자 이름과 토큰을 사용하세요.

Weblate가 변경 사항을 직접 푸시해야 하거나 선택한 워크플로에 푸시 URL이 필요한 경우에만 저장소 푸시 URL 를 구성하세요. Weblate에서 변경사항 푸시 를 참조하세요.

토큰에는 클론을 위한 읽기 접근 권한과 푸시를 위한 쓰기 접근 권한이 필요합니다. 풀 요청이나 병합 요청을 만드는 제공자별 VCS 백엔드에는 별도의 API 자격 증명이 필요할 수 있습니다.

이 방법을 사용하려면:

명령줄 사용을 위한 액세스 토큰 생성 에 설명된 대로 개인 액세스 토큰을 생성합니다.
저장소 URL에 토큰을 포함하세요: https://username:token@github.com/owner/repo.git.

Weblate를 시작하거나 단일 저장소로 작업할 때 적합합니다.

전용 사용자를 사용한 SSH¶

여러 저장소가 있는 설정에서는 Weblate 전용 코드 호스팅 사용자를 사용해 SSH 접근을 사용하세요. 해당 사용자에게 Weblate의 공개 SSH 키를 추가하고, 저장소 접근 권한을 부여한 뒤, 소스 코드 저장소 에서 SSH URL을 사용하세요. 예: git@example.com:group/project.git.

이 방식은 SSH 키 재사용에 대한 제공자 제한도 피합니다. 일부 코드 호스팅 사이트는 공개 SSH 키를 한 번만 추가하거나 단일 사용자 또는 배포 키 항목에만 추가하도록 허용합니다. Weblate의 SSH 키를 전용 사용자에 유지하면 여러 위치에서 키를 재사용하지 않고도 해당 사용자에게 여러 저장소 접근 권한을 부여할 수 있습니다.

이 방식은 개인, 프로젝트 또는 API 접근 토큰이 저장소 URL에 들어가지 않게 합니다. 제공자별 VCS 백엔드를 사용해 풀 요청이나 병합 요청을 만들 때는 제공자 API 자격 증명이 여전히 필요하며, 이러한 자격 증명은 Git 저장소 URL과 별도로 구성됩니다.

GitHub에서는 예를 들어 weblate-bot 같은 전용 사용자를 만들고, 저장소에 GitHub SSH URL(예: git@github.com:owner/repo.git)을 사용하세요.

On Hosted Weblate, use this SSH-user workflow only for direct SSH pushes outside the recommended Hosted Weblate app workflow.

참고

풀 리퀘스트에 GitHub 를 사용할 때, 푸시 브랜치 구성 옵션이 동작에 영향을 미칩니다. 이 옵션이 설정되지 않은 경우 프로젝트가 포크되고 변경 사항은 포크를 통해 푸시됩니다. 이 옵션이 설정된 경우, 변경 사항은 업스트림 저장소의 지정된 브랜치로 푸시됩니다.

GitHub 알림¶

Weblate는 GitHub을 기본적으로 지원합니다.

If you are using Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow. It uses GitHub App webhooks, so you do not need to configure a separate Webhook in GitHub. Components imported from the connected GitHub account also use the App for repository access and pull requests, without inviting the Hosted Weblate weblate GitHub user.

The Hosted Weblate legacy app is kept for existing webhook-only setups. Its deliveries use the generic GitHub webhook URL and are authenticated using a separate webhook secret configured by the Hosted Weblate operator. Use it only when you need the legacy app to deliver GitHub notifications to Hosted Weblate.

For self-hosted Weblate, register the GitHub App using the in-app registration flow described below. Weblate generates the App manifest, GitHub returns the credentials, and they are stored in the database - there is no settings-based configuration.

Registering the GitHub App from Weblate¶

The fastest way to add the GitHub App is to let Weblate generate a GitHub App manifest with the correct permissions, events, and webhook URL pre-filled:

Sign in to Weblate with an account that has management access.
Open Manage → Code-hosting connections → Register Weblate GitHub App.
Fill in the form. The GitHub host defaults to github.com; change it to your GitHub Enterprise hostname if needed. Leave Organization blank to register the App under your personal account, or enter an organization slug to register it under that org.
Click Continue to GitHub and confirm on GitHub’s Create GitHub App page (you can still rename the App there).
GitHub redirects back to Weblate, which exchanges the temporary code for the App ID, private key, webhook secret, and slug and stores them in the database. The Connect GitHub account button is available immediately afterwards.

The manifest requests the permissions and event subscriptions Weblate needs (Contents and Pull requests read/write, Metadata read-only, Organization administration read-only, Workflows read/write, and the Installation, Meta and Push events), and sets the callback, setup and per-app webhook URLs automatically, so no manual GitHub App configuration is required. GitHub delivers the Installation and Installation repositories events to all GitHub Apps by default.

GitHub only offers accounts where the signed-in GitHub user can install or request the app. If an organization is not shown during the install flow, check the user’s organization role and the organization’s GitHub App installation restrictions. On GitHub.com, public apps can be installed on other accounts; private apps can only be installed on the account that owns the app.

Connecting a workspace¶

Connected GitHub accounts are bound to a Weblate workspace. A user with project administration rights for any project in a workspace can connect a GitHub account on that workspace. After connecting, every project in the workspace can import components from repositories the GitHub App installation has access to. For organization accounts, Weblate verifies that the install-time GitHub user can administer the organization installation.

Projects that are not in a workspace cannot connect a GitHub account through the GitHub App.

Components imported through the GitHub App flow use the dedicated GitHub (via Weblate GitHub app) VCS backend. The component settings UI keeps the repository URL read-only to prevent the App-issued credentials from being redirected to an unrelated repository.

App webhook URL¶

Each registered Weblate GitHub App has its own webhook URL containing an opaque token that uniquely identifies a single registered App:

https://weblate.example.com/hooks/integrations/<webhook_token>/

If you are not using a GitHub App, add the Weblate webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below:

페이로드 URL 은 Weblate URL 뒤에 /hooks/github/ 를 덧붙인 형태로 구성됩니다. 예를 들어 호스팅 Weblate 서비스의 경우 https://hosted.weblate.org/hooks/github/ 입니다.

나머지 설정은 기본값 그대로 두셔도 됩니다. Weblate는 두 가지 콘텐츠 유형 모두를 처리할 수 있으며, 오직 push 이벤트만 사용합니다.

GitHub 풀 리퀘스트¶

이는 GitHub API 를 사용하여 Git 위에 얇은 레이어를 추가하여 저장소에 직접 푸시하는 대신 번역 변경 사항을 풀 리퀘스트로 푸시할 수 있게 합니다.

Git 은 변경사항을 저장소에 직접 푸시하는 반면, GitHub 백엔드는 풀 리퀘스트를 만듭니다. 단순히 Git 저장소에 접근하는 데는 후자가 필요하지 않습니다.

풀 리퀘스트를 만들려면 GitHub 를 버전 관리 시스템 로 선택하고 GITHUB_CREDENTIALS 를 구성하세요. GitHub.com의 경우 API 호스트로 api.github.com 을 사용하세요. 토큰은 Weblate가 저장소 콘텐츠를 읽고 쓸 수 있으며 풀 리퀘스트를 만들 수 있어야 합니다. Weblate가 비공개 저장소를 포크해야 한다면 토큰에 관리 권한도 필요할 수 있습니다.

GitLab¶

GitLab 저장소 접근¶

개인 또는 프로젝트 액세스 토큰을 사용한 HTTPS¶

GitLab에서는 저장소에 변경사항을 푸시하려면 토큰에 write_repository 범위가 필요합니다. 프로젝트 액세스 토큰은 푸시를 위해 Developer 역할이 필요합니다.

URL에는 사용자 이름이 포함되어야 합니다. 개인 액세스 토큰의 경우 실제 사용자 이름을 사용합니다: https://user:personal_access_token@gitlab.com/example/example.git. 프로젝트 액세스 토큰의 경우 비어 있지 않은 값을 사용할 수 있습니다: https://example:project_access_token@gitlab.com/example/example.git.

참고

프로젝트 액세스 토큰 사용 규칙은 GitLab 릴리스마다 바뀌었습니다. 현재 요구사항은 비어 있지 않은 값이지만, 이전 버전은 다른 형식(프로젝트 이름, 봇 사용자 이름)을 기대했습니다. 확실하지 않다면 사용하는 버전에 맞는 GitLab 문서를 확인하세요.

전용 사용자를 사용한 SSH¶

GitLab에서는 전용 사용자를 만들고 GitLab SSH URL을 사용하세요. 예: git@gitlab.com:group/project.git.

For Hosted Weblate repositories on GitLab, add the hosted weblate user with the required repository permissions, see 호스팅 Weblate에서 저장소 접근.

GitLab 알림¶

Weblate는 GitLab 훅을 지원합니다. Weblate 설치의 /hooks/gitlab/ URL(예: https://hosted.weblate.org/hooks/gitlab/)을 대상으로 하는 프로젝트 웹훅을 추가하세요.

문제 해결

웹훅이 전달되는지 확인하려면 GitLab 웹훅 요청 히스토리 을 확인하세요.
응답 페이로드에 일치하는 구성요소에 대한 정보가 포함됩니다.

GitLab 병합 요청¶

이 기능은 GitLab API 를 사용하여 Git 위에 얇은 계층을 추가하고, 번역 변경사항을 저장소에 직접 푸시하는 대신 병합 요청으로 푸시할 수 있게 합니다.

Git 저장소에 접근하는 데 이 기능을 사용할 필요는 없습니다. 일반 Git 도 동일하게 동작하며, 차이는 저장소에 푸시하는 방식뿐입니다. Git 에서는 변경사항을 저장소에 직접 푸시하고, GitLab 백엔드는 병합 요청을 만듭니다.

병합 요청을 만들려면 GitLab 을 버전 관리 시스템 로 선택하고 GITLAB_CREDENTIALS 를 구성하세요.

병합 요청을 열기 전에 Weblate가 변경사항을 푸시하는 위치는 푸시 브랜치 구성의 영향을 받습니다.

Gitea, Forgejo, Codeberg¶

Gitea, Forgejo, Codeberg 저장소 접근¶

액세스 토큰을 사용한 HTTPS¶

전용 사용자를 사용한 SSH¶

For Hosted Weblate repositories on Codeberg, add the hosted weblate user with the required repository permissions, see 호스팅 Weblate에서 저장소 접근.

Gitea 알림¶

Weblate는 Gitea 웹훅을 지원합니다. Weblate 설치의 /hooks/gitea/ URL(예: https://hosted.weblate.org/hooks/gitea/)을 대상으로 하는 Push events 이벤트용 Gitea Webhook 을 추가하세요. 저장소 Settings 아래 Webhooks 에서 설정할 수 있습니다.

Forgejo 알림¶

Weblate는 Forgejo 웹훅을 지원합니다. Weblate 설치의 /hooks/forgejo/ URL(예: https://hosted.weblate.org/hooks/forgejo/)을 대상으로 하는 Push events 이벤트용 Forgejo Webhook 을 추가하세요. 저장소 Settings 아래 Webhooks 에서 설정할 수 있습니다.

Gitea 풀 리퀘스트¶

Added in version 4.12.

이 기능은 Gitea API 를 사용하여 Git 위에 얇은 계층을 추가하고, 번역 변경사항을 저장소에 직접 푸시하는 대신 풀 리퀘스트로 푸시할 수 있게 합니다.

Git 저장소에 접근하는 데 이 기능을 사용할 필요는 없습니다. 일반 Git 도 동일하게 동작하며, 차이는 저장소에 푸시하는 방식뿐입니다. Git 에서는 변경사항을 저장소에 직접 푸시하고, Gitea 백엔드는 풀 리퀘스트를 만듭니다.

풀 리퀘스트를 만들려면 Gitea 를 버전 관리 시스템 로 선택하고 GITEA_CREDENTIALS 를 구성하세요.

Bitbucket¶

Bitbucket 저장소 접근¶

액세스 토큰을 사용한 HTTPS¶

전용 사용자를 사용한 SSH¶

For Hosted Weblate repositories on Bitbucket, add the hosted weblate user with the required repository permissions, see 호스팅 Weblate에서 저장소 접근.

직접 푸시하려면 Git 또는 Mercurial 을 저장소 푸시 URL 와 함께 사용하세요.

Bitbucket 알림¶

Weblate는 Bitbucket 웹훅을 지원합니다. 저장소 푸시 시 트리거되고 Weblate 설치의 /hooks/bitbucket/ URL(예: https://hosted.weblate.org/hooks/bitbucket/)을 대상으로 하는 웹훅을 추가하세요.

Bitbucket Data Center 풀 리퀘스트¶

Added in version 4.16.

이 기능은 Bitbucket Data Center API 를 사용하여 Git 위에 얇은 계층을 추가하고, 번역 변경사항을 저장소에 직접 푸시하는 대신 풀 리퀘스트로 푸시할 수 있게 합니다.

경고

이것은 Bitbucket Cloud API를 지원하지 않습니다.

Git 저장소에 접근하는 데 이 기능을 사용할 필요는 없습니다. 일반 Git 도 동일하게 동작하며, 차이는 저장소에 푸시하는 방식뿐입니다. Git 에서는 변경사항을 저장소에 직접 푸시하고, Bitbucket Data Center 백엔드는 풀 리퀘스트를 만듭니다.

풀 리퀘스트를 만들려면 Bitbucket Data Center 를 버전 관리 시스템 로 선택하고 BITBUCKETSERVER_CREDENTIALS 를 구성하세요.

Bitbucket Cloud 풀 리퀘스트¶

Added in version 5.8.

이 기능은 Bitbucket Cloud API 를 사용하여 Git 위에 얇은 계층을 추가하고, 번역 변경사항을 저장소에 직접 푸시하는 대신 풀 리퀘스트로 푸시할 수 있게 합니다.

경고

이것은 Bitbucket Data Center API와 다릅니다.

Git 저장소에 접근하는 데 이 기능을 사용할 필요는 없습니다. 일반 Git 도 동일하게 동작하며, 차이는 저장소에 푸시하는 방식뿐입니다. Git 에서는 변경사항을 저장소에 직접 푸시하고, Bitbucket Cloud 백엔드는 풀 리퀘스트를 만듭니다.

풀 리퀘스트를 만들려면 Bitbucket Cloud 를 버전 관리 시스템 로 선택하고 BITBUCKETCLOUD_CREDENTIALS 를 구성하세요.

Azure DevOps¶

Azure Repos 저장소 접근¶

액세스 토큰을 사용한 HTTPS¶

저장소에 대해 Azure Repos가 표시하는 HTTPS 클론 URL을 사용하세요.

전용 사용자를 사용한 SSH¶

저장소에 대해 Azure Repos가 표시하는 SSH URL을 사용하세요.

Azure Repos 알림¶

Weblate는 Azure Repos 웹훅을 지원합니다. Weblate 설치의 /hooks/azure/ URL(예: https://hosted.weblate.org/hooks/azure/)을 대상으로 하는 Code pushed 이벤트용 웹훅을 추가하세요. Project settings 아래 Service hooks 에서 설정할 수 있습니다.

Azure DevOps 풀 리퀘스트¶

이는 Azure DevOps API 를 사용하여 Git 위에 얇은 레이어를 추가하여 저장소에 직접 푸시하는 대신 번역 변경사항을 풀 리퀘스트로 푸시할 수 있게 합니다.

Git 은 변경사항을 저장소에 직접 푸시하는 반면, Azure DevOps 백엔드는 풀 리퀘스트를 만듭니다. 단순히 Git 저장소에 접근하는 데는 후자가 필요하지 않습니다.

풀 리퀘스트를 만들려면 Azure DevOps 를 버전 관리 시스템 로 선택하고 AZURE_DEVOPS_CREDENTIALS 를 구성하세요.

Pagure¶

Pagure 저장소 접근¶

액세스 토큰을 사용한 HTTPS¶

전용 사용자를 사용한 SSH¶

Pagure 알림¶

Weblate는 Pagure 훅을 지원합니다. Weblate 설치의 /hooks/pagure/ URL(예: https://hosted.weblate.org/hooks/pagure/)을 대상으로 하는 웹훅을 추가하세요. Project options 아래 Activate Web-hooks 에서 설정할 수 있습니다:

Pagure 병합 요청¶

Added in version 4.3.2.

이 기능은 Pagure API 를 사용하여 Git 위에 얇은 계층을 추가하고, 번역 변경사항을 저장소에 직접 푸시하는 대신 병합 요청으로 푸시할 수 있게 합니다.

Git 저장소에 접근하는 데 이 기능을 사용할 필요는 없습니다. 일반 Git 도 동일하게 동작하며, 차이는 저장소에 푸시하는 방식뿐입니다. Git 에서는 변경사항을 저장소에 직접 푸시하고, Pagure 백엔드는 병합 요청을 만듭니다.

병합 요청을 만들려면 Pagure 를 버전 관리 시스템 로 선택하고 PAGURE_CREDENTIALS 를 구성하세요.

기타 워크플로¶

Gitee 저장소 접근¶

액세스 토큰을 사용한 HTTPS¶

전용 사용자를 사용한 SSH¶

Gitee 알림¶

Weblate는 Gitee 웹훅을 지원합니다. Weblate 설치의 /hooks/gitee/ URL(예: https://hosted.weblate.org/hooks/gitee/)을 대상으로 하는 Push 이벤트용 WebHook 을 추가하세요. 저장소 Management 아래 WebHooks 에서 설정할 수 있습니다.

Gerrit 리뷰 요청¶

Gerrit support adds a thin layer atop Git using the git-review tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository.

The optional 푸시 브랜치 setting selects the target branch for the Gerrit review. Leave it empty to use 저장소 브랜치. Use the short branch name, such as main; Weblate and git-review push the review to refs/for/<branch> automatically. Gerrit push options can be appended after % in either setting, for example main%topic=l10n. Gerrit interprets these options as the configured Weblate Gerrit account and applies its own permissions.

The Gerrit documentation has the details on the configuration necessary to set up such repositories. There is no separate code-hosting credential setting for this backend.

Docker 자격 증명¶

For Docker installations, code-hosting API credentials can also be provided through environment variables, see Code-hosting sites credentials.