Integraties codehosten¶

Weblate integreert op verschillende plaatsen met sites voor het hosten van code: toegang tot opslagruimten, inkomende notificaties en het terugplaatsen van vertalingen. De exacte opstelling is afhankelijk van het feit of u Hosted Weblate gebruikt of uw eigen instantie van Weblate uitvoert en of Weblate direct pull of merge requests zou moeten pushen of maken.

Gebruik deze pagina als een provider-geöriënteerde controlelijst. De individuele pagina’s voor de instellingen behouden de canonical verwijzing voor het instellen van syntaxis.

Overzicht instellingen¶

Geef Weblate toegang tot de opslagruimte.
- Voor opslagruimten van GitHub op Hosted Weblate, gebruik de Hosted Weblate-app uit de werkstroom Verbinden met GitHub-account van Weblate. De app geeft de opslagruimte van Hosted Weblate toegang zonder de gehoste gebruiker weblate uit te nodigen.
- Voor andere opslagruimten van Hosted Weblate, en voor directe SSH-pushes buiten de werkstroom van de GitHub-app, voeg de gehoste gebruiker van weblate toe waar het beschikbaar is, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.
- Voor zelfgehoste Weblate, maak een aangewezen gebruiker voor het hosten van code en geef die toegang met Weblate’s SSH-sleutel of een HTTPS-token, bekijk Toegang tot opslagruimten van sites voor het hosten van code (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Configureer Broncode-opslagruimte zodat Weblate de opslagruimte kan klonen.
Configureer inkomende notificaties, zodat Weblate wijzigingen kort na het pushen ophaalt. De webhook voor de opslagruimtere of de app moet verwijzen naar de overeenkomende URL voor de hook van Weblate, en het project moet Hooks inschakelen hebben ingeschakeld.
Bepaal hoe Weblate push-vertalingen terug zou moeten plaatsen:
- Gebruik Git of Mercurial en URL voor pushen naar de opslagruimte om direct te pushen.
- Gebruik een provider-specifiek VCS-backend, zoals GitHub of GitLab, om pull of merge requests te maken. Deze backends hebben inloggegevens voor de API nodig in de instellingen van Weblate.
Stel, optioneel, Push-tak in voor wanneer Weblate naar een branch in de opslagruimte upstream zou moeten pushen in plaats van naar een fork, indien ondersteund.

Wijzigingen vanuit Weblate pushen¶

Elk vertaalonderdeel kan een URL voor pushen ingesteld hebben (bekijk URL voor pushen naar de opslagruimte), en in dat geval zal Weblate in staat zijn de wijziging naar de opslagruimte op afstand te pushen. Weblate kan ook worden geconfigureerd om automatisch wijzigingen te pushen bij elke indiening (commit); dit is standaard ingeschakeld, bekijk Pushen na commit.

Wanneer u niet wilt dat wijzigingen automatisch worden gepusht, kunt u handmatig pushen onder Onderhoud opslagruimte of met de API via wlc push.

Voor het geval dat u geen direct pushen door Weblate wilt, is er ondersteuning voor GitHub pull requests, GitLab verzoeken voor samenvoegen, Gitea pull requests, Pagure verzoeken voor samenvoegen, Azure DevOps pull requests, of reviews van Verzoeken Gerrit review. U kunt deze activeren door te kiezen voor GitHub, GitLab, Gitea, Gerrit, Azure DevOps, of Pagure als Versiebeheersysteem in Configuratie onderdeel.

In het algemeen zijn de volgende opties beschikbaar met Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center en Bitbucket Cloud:

Gewenste instelling	Versiebeheersysteem	URL voor pushen naar de opslagruimte	Push-tak
Niet pushen	Git	leeg	leeg
Direct pushen	Git	SSH URL	leeg
Pushen naar afzonderlijke tak	Git	SSH URL	Naam tak
Niet pushen	Mercurial	leeg	leeg
Direct pushen	Mercurial	SSH URL	leeg
GitHub pull request vanuit fork	GitHub pull requests	leeg	leeg
GitHub pull request vanuit tak	GitHub pull requests	SSH URL [1]	Naam tak
GitLab merge request vanuit fork	GitLab verzoeken voor samenvoegen	leeg	leeg
GitLab merge request vanuit tak	GitLab verzoeken voor samenvoegen	SSH URL [1]	Naam tak
Gitea merge request vanuit fork	Gitea pull requests	leeg	leeg
Gitea merge request vanuit tak	Gitea pull requests	SSH URL [1]	Naam tak
Pagure merge request vanuit fork	Pagure verzoeken voor samenvoegen	leeg	leeg
Pagure merge request vanuit tak	Pagure verzoeken voor samenvoegen	SSH URL [1]	Naam tak
Azure DevOps pull request vanuit fork	Azure DevOps pull requests	leeg	leeg
Azure DevOps pull request vanuit tak	Azure DevOps pull requests	SSH URL [1]	Naam tak
Gerrit review	Verzoeken Gerrit review	SSH URL	Naam doelbranch (optioneel)
Pull request op Bitbucket Data Center uit fork	Pull requesten op Bitbucket Data Center	leeg	leeg
Bitbucket Data Center pull request vanuit tak	Pull requesten op Bitbucket Data Center	SSH URL [1]	Naam tak
Bitbucket Cloud pull request vanuit fork	Bitbucket Cloud pull requests	leeg	leeg
Bitbucket Cloud pull request vanuit tak	Bitbucket Cloud pull requests	SSH URL [1]	Naam tak

GitHub¶

Toegang tot opslagruimten van GitHub¶

Hosted Weblate GitHub-app¶

Op Hosted Weblate is de aanbevolen opstelling om te verbinden met de Hosted Weblate-app vanuit de werkruimte van Weblate waar uw project is opgeslagen. Gebruik de werkstroom Verbinden met GitHub-account, installeer de app voor de GitHub-gebruiker of de organisatie die eigenaar is van uw opslagruimten, geef die toegang tot de opslagruimten die u wilt vertalen, en importeer onderdelen vanuit het verbonden GitHub-account.

De door de app gestuurde werkstroom gebruikt toegangstokens voor de installatie van GitHub voor klonen, pushen van vertaalbranches, maken van pull requests en ontvangen van inkomende notificaties. U hoeft de GitHub-gebruiker weblate van Hosted Weblate niet uit te nodigen of een afzonderlijke webhaak voor de opslagruimte te maken voor onderdelen die op deze manier zijn geïmporteerd.

Gebruik de Hosted Weblate weblate GitHub-gebruiker alleen wanneer u opzettelijk directe SSH-pushes configureert buiten de werkstroom van de GitHub-app, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.

HTTPS met persoonlijk toegangstoken¶

Voor een enkele private opslagruimte is HTTPS-toegang met een toegangstoken gewoonlijk de eenvoudigste opstelling als de provider Git over HTTPS ondersteunt. Gebruik de door de provider vereiste gebruikersnaam en token in Broncode-opslagruimte.

Configureer URL voor pushen naar de opslagruimte alleen als Weblate wijzigingen direct zou moeten pushen of wanneer de gekozen werkstroom een push-URL vereist, bekijk Wijzigingen vanuit Weblate pushen.

Het token heeft leestoegang nodig voor klonen en schrijftoegang voor pushen. Provider-specifieke VCS backends die pull of merge requests maken vereisen misschien afzonderlijke inloggegevens voor de API.

Die benadering gebruiken:

Maak een persoonlijk toegangstoken zoals beschreven in Een toegangstoken maken om te gebruiken op de opdrachtregel.
Neem het token op in de URL van uw opslagruimte: https://gebruikersnaam:token@github.com/eigenaar/repo.git.

Dit is geschikt als u net begint met Weblate of werkt met een enkele opslagruimte.

SSH met een aangewezen gebruiker¶

Voor opstellingen met meerdere opslagruimten: gebruik toegang met SSH met een aangewezen gebruiker voor het hosten van code voor Weblate. Voeg Weblate’s publieke SSH-sleutel toe aan die gebruiker, geef die gebruiker toegang tot de opslagruimten en gebruik SSH-URL’s in Broncode-opslagruimte, bijvoorbeeld git@example.com:group/project.git.

Dat vermijdt ook beperkingen van de provider voor het hergebruiken van SSH-sleutels. Sommige sites voor het hosten van code staan toe dat een publieke SSH-sleutel maar een keer wordt toegevoegd, of alleen aan een enkele gebruiker of uitrol sleutelitem. Weblate’s SSH-sleutel uitgeven aan een aangewezen gebruiker laat die gebruiker toegang krijgen tot meerdere opslagruimten, zonder de sleutel op verscheidene plaatsen te gebruiken.

Dat houdt persoonlijke, project- of API-toegangstokens buiten de URL’s van opslagruimten. Provider API-inloggegevens zijn nog steeds nodig bij het gebruiken van provider-specifieke VCS-backend om pull of merge requests te maken; die inloggegevens worden afzonderlijk geconfigureerd van de URL voor de Git-opslagruimte.

Voor GitHub, maak een aangewezen gebruiker, bijvoorbeeld weblate-bot, en gebruik SSH-URL’s van GitHub voor uw opslagruimten, bijvoorbeeld git@github.com:owner/repo.git.

Op Hosted Weblate, gebruik deze werkstroom SSH-gebruiker alleen voor direct SSH pushen buiten de aanbevolen werkstroom Hosted Weblate-app.

Notitie

Bij het gebruiken van GitHub voor pull requests, beïnvloedt de configuratie van Push-tak het gedrag: indien niet ingesteld wordt het project geforkt en de wijzigingen gepusht via een fork. Indien wel ingesteld, worden wijzigingen gepusht naar de opslagruimte upstream en de gekozen tak.

GitHub notificaties¶

Weblate heeft eigen ondersteuning voor GitHub.

Wanneer u Hosted Weblate gebruikt, gebruik dan de Hosted Weblate app uit Weblate’s werkstroom GitHub- account verbinden. Het gebruikt GitHub App-webhooks, dus hoeft u geen afzonderlijke Webhook in GitHub te configureren. Onderdelen die worden geïmporteerd vanuit het verbonden account van GitHub gebruiken ook de app voor toegang tot de opslagruimte en voor pull requests, zonder de Hosted Weblate weblate GitHub-gebruiker uit te nodigen.

De Hosted Weblate legacy-app is behouden voor bestaande opstellingen van alleen webhaken. Gebruik het alleen als u de verouderde app nodig hebt om GitHub-notificaties af te leveren bij Hosted Weblate.

Voor zelfgehoste Weblate, registreer de GitHub-app met de in-app werkstroom voor registreren, hieronder beschreven. Weblate genereert het app-manifest, GitHub geeft de inloggegevens terug en ze worden opgeslagen in de database - er is geen op instellingen gebaseerde configuratie.

Registreren van de GitHub-app vanuit Weblate¶

De snelste manier om de GitHub-app toe te voegen is door Weblate een manifest voor de GitHub-app te laten maken met de juiste rechten, gebeurtenissen en vooraf ingevulde URL voor de webhook:

Meld u aan bij Weblate met een account dat beheerstoegang heeft.
Open Beheren → Verbindingen codehosten → Weblate GitHub-app registreren.
Vul het formulier in. De GitHub host is standaard github.com; wijzig die naar de naam van uw GitHub Enterprise hostname indien nodig. Laat Organisatie leeg om de app onder uw persoonlijke account te registreren, of voer een organisatie-slug in om hem onder die organisatie te registreren.
Klik op Doorgaan naar GitHub en bevestig op de pagina van GitHub GitHub-app maken (u kunt hier nog steeds de app hernoemen).
GitHub leidt u terug naar Weblate, dat de tijdelijke code voor de app-ID uitwisselt, private sleutel, webhaak geheim en slug en slaat die op in de database. De knop Verbinden met GitHub-account is daarna direct beschikbaar.

Het manifest vraagt de abonnementen voor de rechten en gebeurtenissen op die Weblate nodig heeft (Contents en Pull requests read/write, Metadata read-only, Organization administration read-only, Workflows read/write, en de gebeurtenissen Installation, Meta en Push), en stelt de URL’s voor terugkoppeling, opstelling en per-app webhaak automatisch in, er is dus geen handmatige configuratie voor de GitHub-app nodig. GitHub levert de gebeurtenissen Installation en Installation repositories standaard aan alle GitHub-apps.

GitHub biedt alleen accounts aan waar de aangemelde GitHub-gebruiker de app mag installeren of aanvragen. Als een organisatie niet wordt weergegeven gedurende de werkstroom voor de installatie, controleer dan de rol van de gebruiker in de organisatie en de beperkingen van de installatie van de GitHub-app voor de organisatie. Op GitHub.com mogen publieke apps worden geïnstalleerd onder andere accounts; private apps mogen alleen geïnstalleerd worden onder het account dat eigenaar is van de app.

Verbinden met een werkruimte¶

Verbonden GitHub-accounts zijn gebonden aan een werkruimte van Weblate. Een gebruiker met rechten voor projectbeheer voor elk project in een werkruimte mag een GitHub-account verbinden met die werkruimte. Na het verbinden kan elk project in de werkruimte onderdelen importeren vanuit opslagruimten waar de installatie van de GitHub-app toegang toe heeft. Voor accounts van organisaties verifieert Weblate dat de GitHub-gebruiker, ten tijde van het installeren, de installatie van de organisatie mag beheren.

Projecten die niet in een werkruimte staan, kunnen niet met een GitHub-account verbinden via de GitHub-app.

Onderdelen die zijn geïmporteerd via de werkstroom van de GitHub-app gebruiken de toegewezen VCS-backend GitHub (via Weblate GitHub-app). De gebruikersinterface voor de instellingen van het onderdeel behoudt de URL voor de opslagruimte als alleen-lezen om te voorkomen dat de door de app uitgegeven inloggegevens worden omgeleid naar een niet gerelateerde opslagruimte.

App-webhaak URL¶

Elke geregistreerde Weblate GitHub-app heeft zijn eigen URL voor een webhaak die een ondoorzichtig token bevat dat een enkele geregistreerde app uniek identificeert:

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

Als u geen GitHub-app gebruikt, voeg de Weblate-webhaak toe in de instellingen voor de opslagruimte (Webhooks), voor het ontvangen van notificaties voor elke push naar een opslagruimte van GitHub, zoals weergegeven in de afbeelding hieronder:

De Payload URL bestaat uit uw URL voor Weblate, gevolgd door /hooks/github/, voor de service Hosted Weblate is dit bijvoorbeeld https://hosted.weblate.org/hooks/github/.

U kunt de andere waarden laten staan op de standaard instellingen Weblate kan beide typen inhoud afhandelen en gebruikt alleen de gebeurtenis push.

Zie ook

GitHub pull requests¶

Dit voegt een dunne laag toe bovenop Git met de GitHub API om het pushen van wijzigingen in de vertalingen als pull requests mogelijk te maken, in plaats van ze direct naar de opslagruimte te pushen.

Git pusht wijzigingen direct naar een opslagruimte, terwijl het backend GitHub pull requests maakt. Het laatste is niet nodig om puur toegang te krijgen tot opslagruimten van Git.

Selecteer, om pull requests te maken, GitHub als Versiebeheersysteem en configureer GITHUB_CREDENTIALS. Gebruik voor GitHub.com api.github.com als de API-host. Het token moet Weblate toestaan om inhoud van de opslagruimte te lezen en te schrijven en pull requests te maken. Als Weblate private opslagruimten zou moeten forken, heeft het token misschien ook beheersrechten nodig.

GitLab¶

Toegang tot opslagruimten van GitLab¶

HTTPS met persoonlijk of projecttoegangstoken¶

Voor GitLab moet het token het bereik write_repository hebben om in staat te zijn wijzigingen naar de opslagruimte te pushen. Het project-toegangstoken vereist de rol Ontwikkelaar voor pushen.

De URL moet een gebruikersnaam bevatten. Voor een persoonlijk toegangstoken is dat de feitelijke gebruikersnaam: https://gebruiker:persoonlijk_toegangs_token@gitlab.com/example/example.git. Voor project-toegangstokens mag het een niet lege waarde zijn:https://voorbeeld:project_toegangs_token@gitlab.com/example/example.git.

Notitie

De regels voor het gebruiken van project-toegangstokens zijn gewijzigd tussen uitgaven van GitLab, de niet lege waarde is het huidige vereiste, maar oudere versies hadden verschillende verwachtingen (projectnaam, bot gebruikersnaam). Bekijk de documentatie van GitLab die overeenkomt met uw versie als u er niet zeker van bent.

SSH met een aangewezen gebruiker¶

Voor GitLab, maak een aangewezen gebruiker en gebruik SSH-URL’s van GitLab, bijvoorbeeld git@gitlab.com:group/project.git.

Voor opslagruimten van Hosted Weblate op GitLab, voeg de gehoste gebruiker weblate toe met de vereiste rechten voor de opslagruimte, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.

GitLab notificaties¶

Weblate heeft ondersteuning voor hooks van GitLab. Voeg een webhook voor het project toe met als doel de URL /hooks/gitlab/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/gitlab/.

Probleemoplossing

Controleer GitLab webhook request history als webhooks worden afgeleverd.
De lading van het antwoord bevat informatie over overeenkomende onderdelen.

Zie ook

GitLab verzoeken voor samenvoegen¶

Dit voegt een dunne laag toe bovenop Git met de GitLab API om het pushen van wijzigingen in vertalingen als merge requests mogelijk te maken, in plaats van ze direct naar de opslagruimte te pushen.

Er is geen noodzaak om dit te gebruiken voor toegang tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde. Het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met het backend Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl het backend GitLab een merge request maakt.

Selecteer, om merge requests te maken, GitLab als Versiebeheersysteem en configureer GITLAB_CREDENTIALS.

De configuratie van Push-tak beïnvloedt waar Weblate wijzigingen naartoe pusht voordat het merge request wordt geopend. Als dit niet is ingesteld, wordt het project geforkt en de wijzigingen gepusht via een fork. Indien het wel is ingesteld, worden wijzigingen gepusht naar de opslagruimte upstream en gekozen tak.

Gitea, Forgejo en Codeberg¶

Gitea, Forgejo en Codeberg toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

SSH met een aangewezen gebruiker¶

Voor opslagruimten van Hosted Weblate op Codeberg, voeg de gehoste gebruiker weblate toe met de vereiste rechten voor de opslagruimte, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.

Gitea notificaties¶

Weblate heeft ondersteuning voor webhooks van Gitea. Voeg een Gitea Webhook toe voor de gebeurtenis Push events met als doel de URL /hooks/gitea/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/gitea/. Dit kan worden gedaan in Webhooks onder Settings voor de opslagruimte.

Zie ook

Forgejo notificaties¶

Weblate heeft ondersteuning voor webhooks van Forgejo. Voeg een Forgejo Webhook toe voor de gebeurtenis Push events met als doel de URL /hooks/forgejo/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/forgejo/. Dit kan worden gedaan in Webhooks onder Settings voor de opslagruimte.

Zie ook

Gitea pull requests¶

Added in version 4.12.

Dit voegt een dunne laag toe bovenop Git met behulp van de Gitea API om wijzigingen in vertalingen als pull requests te kunnen pushen, in plaats van ze direct naar de opslagruimte te pushen.

Het is niet nodig om dit te gebruiken voor toegang tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde. Het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen direct naar de opslagruimte gepusht, terwijl de backend Gitea pull requests maakt.

Selecteer, om pull requests te maken, Gitea als Versiebeheersysteem en configureer GITEA_CREDENTIALS.

Bitbucket¶

Bitbucket toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

SSH met een aangewezen gebruiker¶

Voor opslagruimten van Hosted Weblate op BitBucket, voeg de gehoste gebruiker weblate toe met de vereiste rechten voor de opslagruimte, bekijk Toegang tot opslagruimten vanuit Hosted Weblate.

Direct pushen, gebruik Git of Mercurial met URL voor pushen naar de opslagruimte.

Bitbucket notificaties¶

Weblate heeft ondersteuning voor webhooks van Bitbucket. Voeg een webhook toe die wordt geactiveerd bij pushen vanuit de opslagruimte, met als doel de URL /hooks/bitbucket/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/bitbucket/.

Zie ook

Pull requesten op Bitbucket Data Center¶

Added in version 4.16.

Dit voegt een dunne laag toe bovenop Git die de Bitbucket Data Center API gebruikt om wijzigingen in vertalingen als pull requesten te pushen, in plaats van ze direct naar de opslagruimte te pushen.

Waarschuwing

Dit ondersteunt niet Bitbucket Cloud API.

Er is geen noodzaak om dit te gebruiken om toegang te krijgen tot opslagruimten van Git, gewoonlijk werkt Git hetzelfde. Het enige verschil is hoe het pushen naar een opslagruimte wordt afgehandeld. Met Git worden wijzigingen rechtstreeks naar de opslagruimte gepusht, terwijl de backend Bitbucket Data Center een pull request maakt.

Selecteer, om pull requests te maken, Bitbucket Data Center als Versiebeheersysteem en configureer BITBUCKETSERVER_CREDENTIALS.

Bitbucket Cloud pull requests¶

Added in version 5.8.

Dit voegt een dunne laag toe bovenop Git met behulp van de Bitbucket Cloud API om wijzigingen in vertalingen als pull requests te kunnen pushen, in plaats van ze direct naar de opslagruimte te pushen.

Waarschuwing

Dit is anders dan in de Bitbucket data Center API.

Selecteer, om pull requests te maken, Bitbucket Cloud als Versiebeheersysteem en configureer BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Azure Repos toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

Gebruik de HTTPS-URL voor klonen die door Azure Repos voor de opslagruimte wordt weergegeven.

SSH met een aangewezen gebruiker¶

Gebruik de SSH-URL die door Azure Repos voor de opslagruimte wordt weergegeven.

Azure Repos notificaties¶

Weblate heeft ondersteuning voor webhooks van Azure Repos. Voeg een webhook toe voor de gebeurtenis Code pushed met als doel de URL /hooks/azure/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/azure/. Dit kan worden gedaan in Service hooks onder Project settings.

Zie ook

Azure DevOps pull requests¶

Dit voegt eenvoudigweg een dunne laag toe bovenop Git die de Azure DevOps API gebruikt om wijzigingen in vertalingen als pull requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.

Git pusht wijzigingen direct naar een opslagruimte, terwijl de backend Azure DevOps pull requests maakt. Het laatste is niet nodig om alleen toegang te krijgen tot opslagruimten van Git.

Selecteer, om pull requests te maken, Azure DevOps als Versiebeheersysteem en configureer AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Pagure toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

SSH met een aangewezen gebruiker¶

Pagure notificaties¶

Weblate heeft ondersteuning voor hooks van Pagure. Voeg een webhook toe met als doel de URL /hooks/pagure/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/pagure/. Dit kan worden gedaan in Activate Web-hooks onder Project options:

Zie ook

Pagure verzoeken voor samenvoegen¶

Added in version 4.3.2.

Dit voegt een dunne laag toe bovenop Git die de Pagure API gebruikt om wijzigingen in vertalingen als merge requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.

Selecteer, om merge requests te maken, Pagure als Versiebeheersysteem en configureer PAGURE_CREDENTIALS.

Andere werkstromen¶

Gitee toegang tot opslagruimte¶

HTTPS met een persoonlijk toegangstoken¶

SSH met een aangewezen gebruiker¶

Gitee notificaties¶

Weblate heeft ondersteuning voor webhooks van Gitee. Voeg een WebHook toe voor de gebeurtenis Push met als doel de URL /hooks/gitee/ op uw installatie van Weblate, bijvoorbeeld https://hosted.weblate.org/hooks/gitee/. Dit kan worden gedaan in WebHooks onder Management van de opslagruimte.

Zie ook

Verzoeken Gerrit review¶

Ondersteuning van Gerrit voegt een dunne laag toe bovenop Git, die het programma git-review gebruikt om wijzigingen in vertalingen als Gerrit review requests te pushen, in plaats van ze direct naar de opslagruimte te pushen.

De optionele instelling Push-tak selecteert de doelbranch voor de review van Gerrit. Laat die leeg om Tak opslagruimte te gebruiken. Gebruik de verkorte branchnaam, zoals main; Weblate en git-review pushen de review automatisch naar refs/for/<branch>. Opties voor pushen van Gerrit kunnen worden toegevoegd na % in elke instelling, bijvoorbeeld main%topic=l10n. Gerrit interpreteert deze opties als het geconfigureerde Weblate-account voor Gerrit en past zijn eigen rechten toe.

De documentatie van Gerrit heeft de details voor de noodzakelijke configuratie om dergelijke opslagruimten op te stellen. Er is geen afzonderlijke instelling voor inloggegevens voor codehosten voor dit backend.

Inloggegevens Docker¶

Voor installaties van Docker kunnen inloggegevens voor de API van codehosten ook worden opgegeven met omgevingsvariabelen, bekijk Inloggegevens sites hosten van code.