ການເຊື່ອມຕໍ່ກັບບໍລິການຝາກໂຄ້ດ¶

Weblate ເຊື່ອມຕໍ່ກັບເວັບໄຊບໍລິການຝາກໂຄ້ດໃນຫຼາຍພາກສ່ວນຄື: ການເຂົ້າເຖິງຄັງເກັບ (repository), ການແຈ້ງເຕືອນຂາເຂົ້າ, ແລະ ການສົ່ງຄຳແປຄືນ. ການຕັ້ງຄ່າທີ່ຊັດເຈນແມ່ນຂຶ້ນກັບວ່າເຈົ້າໃຊ້ Hosted Weblate ຫຼື ຕິດຕັ້ງ Weblate ເອງ, ແລະ ຂຶ້ນກັບວ່າ Weblate ຄວນສົ່ງໂຄ້ດ (push) ໂດຍກົງ ຫຼື ສ້າງ pull request ຫຼື merge request.

ໃຊ້ໜ້ານີ້ເປັນລາຍການກວດສອບຕາມຜູ້ໃຫ້ບໍລິການ. ໜ້າການຕັ້ງຄ່າແຕ່ລະໜ້າຍັງຄົງເປັນການອ້າງອີງຫຼັກສຳລັບ Syntax ຂອງການຕັ້ງຄ່າ.

ພາບລວມການຕັ້ງຄ່າ¶

ໃຫ້ສິດ Weblate ໃນການເຂົ້າເຖິງຣີໂພຊິທໍຣີ.
- ສຳລັບຣີໂພຊິທໍຣີ GitHub ບົນ Hosted Weblate, ໃຫ້ໃຊ້ Hosted Weblate app ຈາກຂັ້ນຕອນ Connect GitHub account ຂອງ Weblate. ແອັບດັ່ງກ່າວຈະໃຫ້ສິດ Hosted Weblate ໃນການເຂົ້າເຖິງຣີໂພຊິທໍຣີໂດຍບໍ່ຕ້ອງເຊີນຜູ້ໃຊ້ hosted weblate.
- ສຳລັບຣີໂພຊິທໍຣີ Hosted Weblate ອື່ນໆ, ແລະສຳລັບການ SSH Push ໂດຍກົງນອກຂັ້ນຕອນການເຮັດວຽກຂອງ GitHub App, ໃຫ້ເພີ່ມຜູ້ໃຊ້ hosted weblate ໃນບ່ອນທີ່ມີໃຫ້, ເບິ່ງ ການເຂົ້າເຖິງຄັງເກັບຈາກ Hosted Weblate.
- ສຳລັບ Weblate ທີ່ຕິດຕັ້ງເອງ, ໃຫ້ສ້າງຜູ້ໃຊ້ສຳລັບການຝາກໂຄ້ດໂດຍສະເພາະ ແລະ ອະນຸຍາດການເຂົ້າເຖິງໂດຍໃຊ້ກຸນແຈ SSH ຂອງ Weblate ຫຼື ໂທເຄັນ HTTPS, ເບິ່ງທີ່ ການເຂົ້າເຖິງຄັງເກັບໂຄ້ດໃນເວັບໄຊຝາກໂຄ້ດ (GitHub, GitLab, Bitbucket, Azure DevOps, ...).
ຕັ້ງຄ່າ ຄັງເກັບຊອດໂຄ້ດ ເພື່ອໃຫ້ Weblate ສາມາດ Clone ຣີໂພຊິທໍຣີໄດ້.
Configure incoming notifications so Weblate pulls changes soon after a push. The repository webhook or app must point to the matching Weblate hook URL, and the project must have ເປີດໃຊ້ Hooks enabled. Component ຄັງເກັບຊອດໂຄ້ດ must match a repository URL from the webhook payload; see ເປົ້າໝາຍ Webhook ທີ່ກົງກັນ.
ຕັດສິນໃຈວ່າ Weblate ຄວນ Push ການແປກັບຄືນແນວໃດ:
- ໃຊ້ Git ຫຼື Mercurial ແລະ URL ສຳລັບ push ຄັງເກັບ ເພື່ອ Push ໂດຍກົງ.
- ໃຊ້ VCS back-end ສະເພາະຜູ້ໃຫ້ບໍລິການ, ເຊັ່ນ GitHub ຫຼື GitLab, ເພື່ອສ້າງ Pull ຫຼື Merge request. back-end ເຫຼົ່ານີ້ຕ້ອງການ API credentials ໃນການຕັ້ງຄ່າຂອງ Weblate.
ທາງເລືອກ, ຕັ້ງຄ່າ ສາຂາທີ່ຈະ push ເມື່ອ Weblate ຄວນ Push ໄປຍັງ Branch ໃນຣີໂພຊິທໍຣີຕົ້ນທາງ ແທນທີ່ຈະໃຊ້ Fork ໃນກໍລະນີທີ່ມີການຮອງຮັບ.

ການ Push ການປ່ຽນແປງຈາກ Weblate¶

ແຕ່ລະອົງປະກອບການແປສາມາດມີ URL ສຳລັບ Push (ເບິ່ງ URL ສຳລັບ push ຄັງເກັບ), ແລະໃນກໍລະນີນັ້ນ Weblate ຈະສາມາດ Push ການປ່ຽນແປງໄປຍັງຣີໂພຊິທໍຣີທາງໄກໄດ້. Weblate ຍັງສາມາດຕັ້ງຄ່າໃຫ້ Push ການປ່ຽນແປງອັດຕະໂນມັດໃນທຸກຄອມມິດ; ສິ່ງນີ້ຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ, ເບິ່ງ Push ເມື່ອບັນທຶກການປ່ຽນແປງ (Commit).

ຖ້າທ່ານບໍ່ຕ້ອງການໃຫ້ການປ່ຽນແປງຖືກ Push ໂດຍອັດຕະໂນມັດ, ທ່ານສາມາດ Push ດ້ວຍຕົນເອງພາຍໃຕ້ Repository maintenance ຫຼືໃຊ້ API ຜ່ານ wlc push.

ໃນກໍລະນີທີ່ທ່ານບໍ່ຕ້ອງການການ Push ໂດຍກົງຈາກ Weblate, ມີການຮອງຮັບ GitHub Pull request, GitLab Merge request, Gitea Pull request, Pagure Merge request, Azure DevOps Pull request ຫຼືການກວດສອບ ຄຳຮ້ອງຂໍການກວດສອບ Gerrit. ທ່ານສາມາດເປີດໃຊ້ສິ່ງເຫຼົ່ານີ້ໄດ້ໂດຍການເລືອກ GitHub, GitLab, Gitea, Gerrit, Azure DevOps ຫຼື Pagure ເປັນ ແອັບ Weblate GitHub ໃນ ການຕັ້ງຄ່າ Component.

ໂດຍລວມແລ້ວ, ທາງເລືອກຕໍ່ໄປນີ້ມີໃຫ້ໃຊ້ກັບ Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center ແລະ Bitbucket Cloud:

ການຕັ້ງຄ່າທີ່ຕ້ອງການ	ແອັບ Weblate GitHub	URL ສຳລັບ push ຄັງເກັບ	ສາຂາທີ່ຈະ push
ບໍ່ມີການ Push	Git	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
Push ໂດຍກົງ	Git	URL ຂອງ SSH	ຫວ່າງເປົ່າ
Push ໄປຍັງ Branch ແຍກ	Git	URL ຂອງ SSH	ຊື່ Branch
ບໍ່ມີການ Push	Mercurial	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
Push ໂດຍກົງ	Mercurial	URL ຂອງ SSH	ຫວ່າງເປົ່າ
GitHub pull request ຈາກ Fork	GitHub Pull request	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
GitHub pull request ຈາກ Branch	GitHub Pull request	URL ຂອງ SSH [1]	ຊື່ Branch
GitLab merge request ຈາກ Fork	GitLab Merge request	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
GitLab merge request ຈາກ Branch	GitLab Merge request	URL ຂອງ SSH [1]	ຊື່ Branch
Gitea merge request ຈາກ Fork	Gitea Pull request	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
Gitea merge request ຈາກ Branch	Gitea Pull request	URL ຂອງ SSH [1]	ຊື່ Branch
Pagure merge request ຈາກ Fork	Pagure Merge request	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
Pagure merge request ຈາກ Branch	Pagure Merge request	URL ຂອງ SSH [1]	ຊື່ Branch
Azure DevOps pull request ຈາກ Fork	Azure DevOps Pull request	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
Azure DevOps pull request ຈາກ Branch	Azure DevOps Pull request	URL ຂອງ SSH [1]	ຊື່ Branch
ການກວດສອບ Gerrit	ຄຳຮ້ອງຂໍການກວດສອບ Gerrit	URL ຂອງ SSH	ຊື່ Branch ປາຍທາງ (ທາງເລືອກ)
Bitbucket Data Center pull request ຈາກ Fork	Bitbucket Data Center Pull request	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
Bitbucket Data Center pull request ຈາກ Branch	Bitbucket Data Center Pull request	URL ຂອງ SSH [1]	ຊື່ Branch
Bitbucket Cloud pull request ຈາກ Fork	Bitbucket Cloud Pull request	ຫວ່າງເປົ່າ	ຫວ່າງເປົ່າ
Bitbucket Cloud pull request ຈາກ Branch	Bitbucket Cloud Pull request	URL ຂອງ SSH [1]	ຊື່ Branch

GitHub¶

ການເຂົ້າເຖິງຣີໂພຊິທໍຣີ GitHub¶

ແອັບ Hosted Weblate GitHub¶

ໃນ Hosted Weblate, ການຕັ້ງຄ່າທີ່ແນະນຳແມ່ນໃຫ້ເຊື່ອມຕໍ່ແອັບ Hosted Weblate ຈາກພື້ນທີ່ເຮັດວຽກ Weblate ທີ່ໂຄງການຂອງທ່ານຢູ່. ໃຫ້ໃຊ້ຂັ້ນຕອນ Connect GitHub account, ຕິດຕັ້ງແອັບໃນຜູ້ໃຊ້ GitHub ຫຼື ອົງກອນທີ່ເປັນເຈົ້າຂອງຄັງເກັບລະຫັດຂອງທ່ານ, ອະນຸຍາດໃຫ້ເຂົ້າເຖິງຄັງເກັບລະຫັດທີ່ທ່ານຕ້ອງການແປ, ແລະ ນຳເຂົ້າສ່ວນປະກອບຈາກບັນຊີ GitHub ທີ່ເຊື່ອມຕໍ່ແລ້ວ.

ຂັ້ນຕອນການເຮັດວຽກທີ່ໃຊ້ App ຈະໃຊ້ GitHub installation access token ສຳລັບການ Clone, Push branch ການແປ, ສ້າງ Pull request ແລະຮັບການແຈ້ງເຕືອນຂາເຂົ້າ. ທ່ານບໍ່ຈຳເປັນຕ້ອງເຊີນຜູ້ໃຊ້ GitHub weblate ຂອງ Hosted Weblate ຫຼືຕັ້ງຄ່າ Webhook ຂອງຣີໂພຊິທໍຣີແຍກຕ່າງຫາກສຳລັບອົງປະກອບທີ່ອິມພອດດ້ວຍວິທີນີ້.

ໃຊ້ຜູ້ໃຊ້ GitHub weblate ຂອງ Hosted Weblate ເມື່ອທ່ານຕັ້ງໃຈຕັ້ງຄ່າການ Push SSH ໂດຍກົງນອກຂັ້ນຕອນການເຮັດວຽກຂອງ GitHub App ເທົ່ານັ້ນ, ເບິ່ງ ການເຂົ້າເຖິງຄັງເກັບຈາກ Hosted Weblate.

HTTPS ດ້ວຍ Personal Access Token¶

ສຳລັບຄັງເກັບຂໍ້ມູນ (repository) ສ່ວນຕົວອັນດຽວ, ການເຂົ້າເຖິງຜ່ານ HTTPS ດ້ວຍ access token ມັກຈະເປັນວິທີ ການຕັ້ງຄ່າທີ່ງ່າຍທີ່ສຸດ ຫາກຜູ້ບໍລິການຮອງຮັບ Git ຜ່ານ HTTPS. ໃຫ້ໃຊ້ຊື່ຜູ້ໃຊ້ ແລະ ໂທເຄັນຕາມທີ່ຜູ້ບໍລິການກຳນົດ ໃນ ຄັງເກັບຊອດໂຄ້ດ.

ຕັ້ງຄ່າ URL ສຳລັບ push ຄັງເກັບ ກໍຕໍ່ເມື່ອ Weblate ຄວນດັນ (push) ການປ່ຽນແປງໂດຍກົງ ຫຼື ເມື່ອຂັ້ນຕອນການເຮັດວຽກ ທີ່ເລືອກຕ້ອງການ URL ສຳລັບການດັນຂໍ້ມູນ, ເບິ່ງ ການ Push ການປ່ຽນແປງຈາກ Weblate.

ໂທເຄັນຕ້ອງການສິດໃນການອ່ານສຳລັບການໂຄນ (cloning) ແລະ ສິດໃນການຂຽນສຳລັບການດັນ (pushing). ລະບົບຫຼັງບ້ານຂອງ VCS ສະເພາະຜູ້ບໍລິການທີ່ສ້າງ pull ຫຼື merge requests ອາດຈະຕ້ອງການຂໍ້ມູນຢືນຢັນຕົວຕົນ API ແຍກຕ່າງຫາກ.

ເພື່ອໃຊ້ວິທີນີ້:

ສ້າງ Personal Access Token ຕາມທີ່ອະທິບາຍໃນ ການສ້າງ Access Token ສຳລັບການໃຊ້ Command-line.
ລວມ Token ເຂົ້າໃນ URL ຣີໂພຊິທໍຣີຂອງທ່ານ: https://username:token@github.com/owner/repo.git.

ວິທີນີ້ເໝາະສົມເມື່ອທ່ານເລີ່ມຕົ້ນກັບ Weblate ຫຼືເຮັດວຽກກັບຣີໂພຊິທໍຣີດຽວ.

SSH ດ້ວຍຜູ້ໃຊ້ສະເພາະ¶

ສຳລັບການຕັ້ງຄ່າທີ່ມີຫຼາຍຄັງເກັບຂໍ້ມູນ, ໃຫ້ໃຊ້ການເຂົ້າເຖິງຜ່ານ SSH ດ້ວຍບັນຊີຜູ້ໃຊ້ສະເພາະສຳລັບ Weblate. ເພີ່ມ public SSH key ຂອງ Weblate ໃຫ້ກັບຜູ້ໃຊ້ນັ້ນ, ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ນັ້ນເຂົ້າເຖິງຄັງເກັບຂໍ້ມູນຕ່າງໆ, ແລະ ໃຊ້ SSH URLs ໃນ ຄັງເກັບຊອດໂຄ້ດ, ຕົວຢ່າງ: git@example.com:group/project.git.

ສິ່ງນີ້ຍັງຊ່ວຍຫຼີກລ່ຽງຂໍ້ຈຳກັດຂອງຜູ້ບໍລິການໃນການໃຊ້ SSH key ຊ້ຳ. ບາງເວັບໄຊຕ໌ທີ່ຝາກໂຄ້ດອະນຸຍາດໃຫ້ເພີ່ມ public SSH key ໄດ້ພຽງຄັ້ງດຽວ, ຫຼື ໃຫ້ກັບຜູ້ໃຊ້ດຽວ ຫຼື deploy key ອັນດຽວເທົ່ານັ້ນ. ການຮັກສາ SSH key ຂອງ Weblate ໄວ້ກັບຜູ້ໃຊ້ສະເພາະ ຈະຊ່ວຍໃຫ້ຜູ້ໃຊ້ນັ້ນໄດ້ຮັບອະນຸຍາດໃຫ້ເຂົ້າເຖິງຫຼາຍຄັງເກັບຂໍ້ມູນໄດ້ ໂດຍບໍ່ຕ້ອງໃຊ້ຄີຊ້ຳກັນໃນຫຼາຍບ່ອນ.

ສິ່ງນີ້ຈະຊ່ວຍຮັກສາໂທເຄັນສ່ວນຕົວ, ໂຄງການ ຫຼື API ໃຫ້ຢູ່ນອກ URL ຂອງຄັງເກັບຂໍ້ມູນ. ຂໍ້ມູນຢືນຢັນຕົວຕົນ API ຂອງຜູ້ບໍລິການຍັງຄົງຈຳເປັນເມື່ອໃຊ້ລະບົບຫຼັງບ້ານຂອງ VCS ສະເພາະຜູ້ບໍລິການເພື່ອສ້າງ pull ຫຼື merge requests; ຂໍ້ມູນຢືນຢັນຕົວຕົນເຫຼົ່ານັ້ນຈະຖືກຕັ້ງຄ່າແຍກຕ່າງຫາກຈາກ URL ຂອງຄັງເກັບຂໍ້ມູນ Git.

ສຳລັບ GitHub, ໃຫ້ສ້າງຜູ້ໃຊ້ສະເພາະ, ຕົວຢ່າງ weblate-bot, ແລະໃຊ້ GitHub SSH URL ສຳລັບຣີໂພຊິທໍຣີຂອງທ່ານ, ຕົວຢ່າງ git@github.com:owner/repo.git.

ບົນ Hosted Weblate, ໃຫ້ໃຊ້ຂັ້ນຕອນການເຮັດວຽກຂອງ SSH-user ນີ້ສຳລັບການ Push SSH ໂດຍກົງນອກຂັ້ນຕອນການເຮັດວຽກ Hosted Weblate app ທີ່ແນະນຳເທົ່ານັ້ນ.

Note

ເມື່ອໃຊ້ GitHub ສຳລັບ Pull request, ການຕັ້ງຄ່າ ສາຂາທີ່ຈະ push ຈະສົ່ງຜົນຕໍ່ພຶດຕິກຳ: ຖ້າບໍ່ໄດ້ຕັ້ງຄ່າ, ໂປຣເຈັກຈະຖືກ Fork ແລະການປ່ຽນແປງຈະຖືກ Push ຜ່ານ Fork. ຖ້າຕັ້ງຄ່າ, ການປ່ຽນແປງຈະຖືກ Push ໄປຍັງຣີໂພຊິທໍຣີຕົ້ນທາງ ແລະ Branch ທີ່ເລືອກ.

ການແຈ້ງເຕືອນ GitHub¶

Weblate ມາພ້ອມກັບການຮອງຮັບ GitHub ແບບເນທີຟ.

ຖ້າທ່ານໃຊ້ Hosted Weblate, ໃຫ້ໃຊ້ Hosted Weblate app ຈາກຂັ້ນຕອນ Connect GitHub account ຂອງ Weblate. ມັນໃຊ້ GitHub App webhooks, ສະນັ້ນທ່ານບໍ່ຈຳເປັນຕ້ອງຕັ້ງຄ່າ Webhook ແຍກຕ່າງຫາກໃນ GitHub. ອົງປະກອບທີ່ອິມພອດຈາກບັນຊີ GitHub ທີ່ເຊື່ອມຕໍ່ຍັງໃຊ້ App ສຳລັບການເຂົ້າເຖິງຣີໂພຊິທໍຣີ ແລະ Pull request, ໂດຍບໍ່ຕ້ອງເຊີນຜູ້ໃຊ້ GitHub weblate ຂອງ Hosted Weblate.

ແອັບແບບເກົ່າຂອງ Hosted Weblate legacy app ແມ່ນຖືກເກັບໄວ້ສຳລັບການຕັ້ງຄ່າທີ່ໃຊ້ແຕ່ webhook ເທົ່ານັ້ນ. ການສົ່ງຂໍ້ມູນຈະໃຊ້ URL webhook ຂອງ GitHub ແບບທົ່ວໄປ ແລະ ຢືນຢັນຕົວຕົນໂດຍໃຊ້ລະຫັດລັບ webhook ທີ່ແຍກຕ່າງຫາກເຊິ່ງຕັ້ງຄ່າໂດຍຜູ້ດູແລ Hosted Weblate. ໃຊ້ແອັບນີ້ສະເພາະເມື່ອທ່ານຕ້ອງການໃຫ້ແອັບແບບເກົ່າສົ່ງການແຈ້ງເຕືອນ GitHub ໄປຫາ Hosted Weblate ເທົ່ານັ້ນ.

ສຳລັບ self-hosted Weblate, ໃຫ້ລົງທະບຽນ GitHub App ໂດຍໃຊ້ຂັ້ນຕອນການລົງທະບຽນໃນແອັບທີ່ອະທິບາຍຂ້າງລຸ່ມ. Weblate ຈະສ້າງ App manifest, GitHub ສົ່ງຄືນ credentials, ແລະພວກມັນຈະຖືກຈັດເກັບໄວ້ໃນຖານຂໍ້ມູນ - ບໍ່ມີການຕັ້ງຄ່າແບບອີງໃສ່ໄຟລ໌ການຕັ້ງຄ່າ.

ການລົງທະບຽນ GitHub App ຈາກ Weblate¶

ວິທີທີ່ໄວທີ່ສຸດໃນການເພີ່ມ GitHub App ແມ່ນໃຫ້ Weblate ສ້າງ GitHub App manifest ພ້ອມດ້ວຍການອະນຸຍາດ, ເຫດການ, ແລະ Webhook URL ທີ່ຖືກຕ້ອງທີ່ຕື່ມໄວ້ລ່ວງໜ້າ:

ເຂົ້າສູ່ລະບົບ Weblate ດ້ວຍບັນຊີທີ່ມີສິດໃນການຈັດການ.
ເປີດ ຈັດການ → ການເຊື່ອມຕໍ່ກັບບ່ອນຝາກໂຄ້ດ → ລົງທະບຽນ Weblate GitHub App.
ຕື່ມຂໍ້ມູນໃສ່ຟອມ. GitHub host ຈະເປັນ github.com ໂດຍຄ່າເລີ່ມຕົ້ນ; ປ່ຽນມັນເປັນຊື່ໂຮສຕ໌ GitHub Enterprise ຂອງທ່ານຖ້າຈຳເປັນ. ປ່ອຍ Organization ຫວ່າງໄວ້ເພື່ອລົງທະບຽນ App ພາຍໃຕ້ບັນຊີສ່ວນຕົວຂອງທ່ານ, ຫຼືໃສ່ Organization slug ເພື່ອລົງທະບຽນພາຍໃຕ້ອົງກອນນັ້ນ.
ຄລິກ Continue to GitHub ແລະຢືນຢັນໃນໜ້າ Create GitHub App ຂອງ GitHub (ທ່ານຍັງສາມາດປ່ຽນຊື່ App ຢູ່ທີ່ນັ້ນໄດ້).
GitHub ຈະ Redirect ກັບມາທີ່ Weblate, ເຊິ່ງຈະແລກປ່ຽນລະຫັດຊົ່ວຄາວສຳລັບ App ID, private key, webhook secret ແລະ slug ແລະຈັດເກັບພວກມັນໄວ້ໃນຖານຂໍ້ມູນ. ປຸ່ມ Connect GitHub account ຈະມີໃຫ້ໃຊ້ງານທັນທີຫຼັງຈາກນັ້ນ.

Manifest ຈະຮ້ອງຂໍສິດອະນຸຍາດ ແລະ ການຕິດຕາມເຫດການທີ່ Weblate ຕ້ອງການ (ການອ່ານ/ຂຽນ Contents ແລະ Pull requests, ການອ່ານຢ່າງດຽວສຳລັບ Metadata, ການອ່ານຢ່າງດຽວສຳລັບ Organization administration, ການອ່ານ/ຂຽນ Workflows, ແລະ ເຫດການ Installation, Meta ແລະ Push), ພ້ອມທັງຕັ້ງຄ່າ URL ສຳລັບ callback, setup ແລະ webhook ຂອງແຕ່ລະແອັບໂດຍອັດຕະໂນມັດ, ດັ່ງນັ້ນຈຶ່ງບໍ່ຈຳເປັນຕ້ອງຕັ້ງຄ່າ GitHub App ດ້ວຍຕົນເອງ. ຕາມປົກກະຕິແລ້ວ GitHub ຈະສົ່ງເຫດການ Installation ແລະ Installation repositories ໄປໃຫ້ທຸກ GitHub Apps ຢູ່ແລ້ວ.

GitHub ຈະສະເໜີສະເພາະບັນຊີທີ່ຜູ້ໃຊ້ GitHub ທີ່ເຂົ້າສູ່ລະບົບຢູ່ສາມາດຕິດຕັ້ງ ຫຼືຮ້ອງຂໍແອັບໄດ້. ຖ້າອົງກອນບໍ່ປາກົດໃນລະຫວ່າງຂັ້ນຕອນການຕິດຕັ້ງ, ໃຫ້ກວດສອບບົດບາດຂອງຜູ້ໃຊ້ໃນອົງກອນ ແລະຂໍ້ຈຳກັດການຕິດຕັ້ງ GitHub App ຂອງອົງກອນນັ້ນ. ບົນ GitHub.com, ແອັບສາທາລະນະສາມາດຕິດຕັ້ງໄດ້ໃນບັນຊີອື່ນ; ແອັບສ່ວນຕົວສາມາດຕິດຕັ້ງໄດ້ໃນບັນຊີທີ່ເປັນເຈົ້າຂອງແອັບເທົ່ານັ້ນ.

ການເຊື່ອມຕໍ່ Workspace¶

ບັນຊີ GitHub ທີ່ເຊື່ອມຕໍ່ແລ້ວຈະຜູກກັບ Weblate workspace. ຜູ້ໃຊ້ທີ່ມີສິດບໍລິຫານໂຄງການສຳລັບໂຄງການໃດໜຶ່ງໃນ workspace ສາມາດເຊື່ອມຕໍ່ບັນຊີ GitHub ເຂົ້າກັບ workspace ນັ້ນໄດ້. ຫຼັງຈາກເຊື່ອມຕໍ່ແລ້ວ, ທຸກໆໂຄງການໃນ workspace ຈະສາມາດນຳເຂົ້າສ່ວນປະກອບຈາກຄັງເກັບໂຄ້ດທີ່ GitHub App ໄດ້ຮັບສິດເຂົ້າເຖິງ. ສຳລັບບັນຊີອົງກອນ, Weblate ຈະກວດສອບວ່າຜູ້ໃຊ້ GitHub ໃນຂະນະຕິດຕັ້ງນັ້ນມີສິດບໍລິຫານການຕິດຕັ້ງຂອງອົງກອນຫຼືບໍ່.

ໂຄງການທີ່ບໍ່ໄດ້ຢູ່ໃນ workspace ຈະບໍ່ສາມາດເຊື່ອມຕໍ່ບັນຊີ GitHub ຜ່ານ GitHub App ໄດ້.

ການລຶບບັນຊີ GitHub ທີ່ເຊື່ອມຕໍ່ຢູ່ຈະຖອນການຕິດຕັ້ງແອັບຯອອກຈາກ GitHub ນຳ ຫາກບໍ່ມີພື້ນທີ່ເຮັດວຽກ (workspace) ອື່ນຂອງ Weblate ໃຊ້ການຕິດຕັ້ງນັ້ນຢູ່. ຫາກພື້ນທີ່ເຮັດວຽກອື່ນຍັງໃຊ້ຢູ່, Weblate ຈະລຶບພຽງແຕ່ການເຊື່ອມຕໍ່ຂອງພື້ນທີ່ເຮັດວຽກທີ່ເລືອກເທົ່ານັ້ນ. ສ່ວນປະກອບທີ່ນຳເຂົ້າຜ່ານການເຊື່ອມຕໍ່ນັ້ນ ຈະສູນເສຍການເຂົ້າເຖິງຄັງເກັບຂອງພວກເຂົາ. ການລຶບພື້ນທີ່ເຮັດວຽກຈະຖອນການຕິດຕັ້ງບັນຊີທີ່ເຊື່ອມຕໍ່ຢູ່ດ້ວຍວິທີດຽວກັນ.

Weblate ຈະລຶບການເຊື່ອມຕໍ່ອອກ ເຖິງແມ່ນວ່າ GitHub ຈະບໍ່ຮູ້ຈັກການຕິດຕັ້ງນັ້ນແລ້ວກໍຕາມ, ແລະ ຈະເກັບມັນໄວ້ພຽງແຕ່ເມື່ອບໍ່ສາມາດຕິດຕໍ່ GitHub ໄດ້ ເພື່ອໃຫ້ສາມາດລອງລຶບໃໝ່ໄດ້.

ອົງປະກອບທີ່ອິມພອດຜ່ານຂັ້ນຕອນ GitHub App ຈະໃຊ້ VCS back-end ແບບສະເພາະ GitHub (via Weblate GitHub app). UI ການຕັ້ງຄ່າອົງປະກອບຈະເກັບ URL ຣີໂພຊິທໍຣີໄວ້ໃນສະຖານະ Read-only ເພື່ອປ້ອງກັນບໍ່ໃຫ້ Credentials ທີ່ອອກໂດຍ App ຖືກ Redirect ໄປຍັງຣີໂພຊິທໍຣີອື່ນ.

Migrating existing components¶

Weblate ຈະລາຍງານການກວດສອບຂໍ້ມູນສຳລັບສ່ວນປະກອບ Git ແລະ GitHub pull request ທີ່ສາມາດຍ້າຍໄປໃຊ້ Weblate GitHub App ທີ່ລົງທະບຽນແລ້ວ. ໃຫ້ຄລິກທີ່ລິ້ງ ຍ້າຍໄປ GitHub App ຈາກການກວດສອບເພື່ອເບິ່ງສ່ວນປະກອບທັງໝົດໃນພື້ນທີ່ເຮັດວຽກທີ່ມີສິດຍ້າຍ.

ເຊື່ອມຕໍ່ ຫຼື ອັບເດດບັນຊີ GitHub ສຳລັບພື້ນທີ່ເຮັດວຽກ, ໃຫ້ສິດແອັບຯເຂົ້າເຖິງຄັງເກັບທີ່ລະບຸ, ແລະ ເລືອກສ່ວນປະກອບທີ່ຈະຍ້າຍ. Weblate ຈະປ່ຽນສ່ວນປະກອບທີ່ເລືອກໄປໃຊ້ VCS backend ແບບ GitHub (ຜ່ານ Weblate GitHub app), ແທນທີ່ທີ່ຢູ່ຄັງເກັບດ້ວຍ URL ການໂຄລນ HTTPS ມາດຕະຖານ, ແລະ ລຶບ URL ສຳລັບການຍູ້ (push) ທີ່ແຍກຕ່າງຫາກອອກ ເພາະແອັບຯຈະຢືນຢັນຕົວຕົນໃນການຍູ້ຂໍ້ມູນໄປຍັງຄັງເກັບຕົ້ນທາງເອງ.

App Webhook URL¶

ແຕ່ລະ Weblate GitHub App ທີ່ລົງທະບຽນແລ້ວຈະມີ URL webhook ຂອງຕົນເອງ ເຊິ່ງປະກອບມີໂທເຄັນ (opaque token) ທີ່ໃຊ້ລະບຸຕົວຕົນຂອງແອັບທີ່ລົງທະບຽນໄວ້ຢ່າງສະເພາະເຈາະຈົງ:

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

ສ່ວນປະກອບທີ່ໃຊ້ VCS backend ແບບ GitHub (ຜ່ານ Weblate GitHub app) ຈະຖືກຈັບຄູ່ຜ່ານຈຸດເຊື່ອມຕໍ່ (endpoint) ສະເພາະນີ້ເທົ່ານັ້ນ. ຈຸດເຊື່ອມຕໍ່ webhook ຂອງ forge ແບບທົ່ວໄປທັງໝົດ ຈະບໍ່ລວມສ່ວນປະກອບເຫຼົ່ານີ້ເຂົ້າໃນການຈັບຄູ່ ແລະ ການກວດສອບການຕອບກັບ, ລວມທັງ /hooks/github/. ການສົ່ງຂໍ້ມູນ GitHub App ແບບເກົ່າທີ່ສົ່ງໄປຫາຈຸດເຊື່ອມຕໍ່ທົ່ວໄປ ຈະສາມາດຈັບຄູ່ໄດ້ສະເພາະສ່ວນປະກອບທີ່ໃຊ້ VCS backend ທີ່ບໍ່ແມ່ນແອັບຯເທົ່ານັ້ນ.

ຖ້າທ່ານບໍ່ໄດ້ໃຊ້ GitHub App, ໃຫ້ເພີ່ມ Weblate webhook ໃນການຕັ້ງຄ່າຣີໂພຊິທໍຣີ (Webhooks) ເພື່ອຮັບການແຈ້ງເຕືອນໃນທຸກການ Push ໄປຍັງຣີໂພຊິທໍຣີ GitHub, ດັ່ງທີ່ສະແດງໃນຮູບຂ້າງລຸ່ມ:

Payload URL ປະກອບດ້ວຍ URL Weblate ຂອງທ່ານຕາມດ້ວຍ /hooks/github/, ຕົວຢ່າງສຳລັບບໍລິການ Hosted Weblate, ນີ້ຄື https://hosted.weblate.org/hooks/github/.

ທ່ານສາມາດປ່ອຍຄ່າອື່ນໆໄວ້ເປັນຄ່າເລີ່ມຕົ້ນ. Weblate ສາມາດຈັດການກັບ Content type ໄດ້ທັງສອງຢ່າງ ແລະຈະບໍລິໂພກພຽງແຕ່ເຫດການ push ເທົ່ານັ້ນ.

See also

GitHub Pull request¶

ສິ່ງນີ້ຈະເພີ່ມຊັ້ນບາງໆຢູ່ເທິງ Git ໂດຍໃຊ້ GitHub API ເພື່ອອະນຸຍາດໃຫ້ Push ການປ່ຽນແປງການແປເປັນ Pull request, ແທນທີ່ຈະ Push ໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ.

Git Push ການປ່ຽນແປງໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ, ໃນຂະນະທີ່ back-end GitHub ຈະສ້າງ Pull request. ອັນຫຼັງບໍ່ຈຳເປັນສຳລັບການເຂົ້າເຖິງຣີໂພຊິທໍຣີ Git ພຽງຢ່າງດຽວ.

ເພື່ອສ້າງ Pull request, ເລືອກ GitHub ເປັນ ແອັບ Weblate GitHub ແລະຕັ້ງຄ່າ GITHUB_CREDENTIALS. ສຳລັບ GitHub.com, ໃຫ້ໃຊ້ api.github.com ເປັນ API host. Token ຕ້ອງອະນຸຍາດໃຫ້ Weblate ອ່ານ ແລະຂຽນເນື້ອຫາຣີໂພຊິທໍຣີ ແລະສ້າງ Pull request. ຖ້າ Weblate ຄວນ Fork ຣີໂພຊິທໍຣີສ່ວນຕົວ, Token ອາດຈະຕ້ອງການສິດໃນການຈັດການ (administration access).

GitLab¶

ການເຂົ້າເຖິງຣີໂພຊິທໍຣີ GitLab¶

HTTPS ດ້ວຍ Personal ຫຼື Project Access Token¶

ສຳລັບ GitLab, Token ຕ້ອງການ Scope write_repository ເພື່ອໃຫ້ສາມາດ Push ການປ່ຽນແປງໄປຍັງຣີໂພຊິທໍຣີໄດ້. Project access token ຕ້ອງການບົດບາດ Developer ສຳລັບການ Push.

URL ຕ້ອງມີຊື່ຜູ້ໃຊ້. ສຳລັບ Personal access token, ມັນແມ່ນຊື່ຜູ້ໃຊ້ຕົວຈິງ: https://user:personal_access_token@gitlab.com/example/example.git. ສຳລັບ Project access tokens ມັນສາມາດເປັນຄ່າທີ່ບໍ່ຫວ່າງໄດ້: https://example:project_access_token@gitlab.com/example/example.git.

Note

ກົດລະບຽບສຳລັບການໃຊ້ Project access tokens ມີການປ່ຽນແປງລະຫວ່າງການປ່ອຍເວີຊັນຂອງ GitLab, ຄ່າທີ່ບໍ່ຫວ່າງແມ່ນຂໍ້ກຳນົດໃນປະຈຸບັນ, ແຕ່ເວີຊັນເກົ່າອາດມີຄວາມຄາດຫວັງທີ່ແຕກຕ່າງກັນ (ຊື່ໂປຣເຈັກ, ຊື່ຜູ້ໃຊ້ບັອດ). ກວດສອບເອກະສານ GitLab ທີ່ກົງກັບເວີຊັນຂອງທ່ານຖ້າບໍ່ແນ່ໃຈ.

SSH ດ້ວຍຜູ້ໃຊ້ສະເພາະ¶

ສຳລັບ GitLab, ໃຫ້ສ້າງຜູ້ໃຊ້ສະເພາະ ແລະໃຊ້ GitLab SSH URL, ຕົວຢ່າງ git@gitlab.com:group/project.git.

ສຳລັບຣີໂພຊິທໍຣີ Hosted Weblate ບົນ GitLab, ໃຫ້ເພີ່ມຜູ້ໃຊ້ hosted weblate ພ້ອມດ້ວຍສິດຣີໂພຊິທໍຣີທີ່ຈຳເປັນ, ເບິ່ງ ການເຂົ້າເຖິງຄັງເກັບຈາກ Hosted Weblate.

ການແຈ້ງເຕືອນ GitLab¶

Weblate ຮອງຮັບ GitLab hooks. ໃຫ້ເພີ່ມ Project webhook ທີ່ມີປາຍທາງໄປຍັງ URL /hooks/gitlab/ ບົນການຕິດຕັ້ງ Weblate ຂອງທ່ານ, ຕົວຢ່າງ https://hosted.weblate.org/hooks/gitlab/.

ການແກ້ໄຂບັນຫາ

ກວດສອບ ປະຫວັດການຮ້ອງຂໍ Webhook ຂອງ GitLab ວ່າ Webhook ຖືກສົ່ງໄປຫຼືບໍ່.
Payload ການຕອບກັບບັນຈຸຂໍ້ມູນກ່ຽວກັບອົງປະກອບທີ່ກົງກັນ.

See also

GitLab Merge request¶

ສິ່ງນີ້ເພີ່ມຊັ້ນບາງໆຢູ່ເທິງ Git ໂດຍໃຊ້ GitLab API ເພື່ອອະນຸຍາດໃຫ້ Push ການປ່ຽນແປງການແປເປັນ Merge request ແທນທີ່ຈະ Push ໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ.

ບໍ່ຈຳເປັນຕ້ອງໃຊ້ສິ່ງນີ້ເພື່ອເຂົ້າເຖິງຣີໂພຊິທໍຣີ Git, Git ທຳມະດາກໍເຮັດວຽກໄດ້ຄືກັນ, ຄວາມແຕກຕ່າງພຽງຢ່າງດຽວແມ່ນວິທີການ Push ໄປຍັງຣີໂພຊິທໍຣີ. ດ້ວຍ Git ການປ່ຽນແປງຈະຖືກ Push ໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ, ໃນຂະນະທີ່ back-end GitLab ຈະສ້າງ Merge request.

ເພື່ອສ້າງ Merge request, ເລືອກ GitLab ເປັນ ແອັບ Weblate GitHub ແລະຕັ້ງຄ່າ GITLAB_CREDENTIALS.

ການຕັ້ງຄ່າ ສາຂາທີ່ຈະ push ຈະສົ່ງຜົນຕໍ່ບ່ອນທີ່ Weblate Push ການປ່ຽນແປງກ່ອນທີ່ຈະເປີດ Merge request. ຖ້າມັນບໍ່ຖືກຕັ້ງຄ່າ, ໂປຣເຈັກຈະຖືກ Fork ແລະການປ່ຽນແປງຈະຖືກ Push ຜ່ານ Fork. ຖ້າມັນຖືກຕັ້ງຄ່າ, ການປ່ຽນແປງຈະຖືກ Push ໄປຍັງຣີໂພຊິທໍຣີຕົ້ນທາງ ແລະ Branch ທີ່ເລືອກ.

Gitea, Forgejo ແລະ Codeberg¶

ການເຂົ້າເຖິງຣີໂພຊິທໍຣີ Gitea, Forgejo ແລະ Codeberg¶

HTTPS ດ້ວຍ Access Token¶

SSH ດ້ວຍຜູ້ໃຊ້ສະເພາະ¶

ສຳລັບຣີໂພຊິທໍຣີ Hosted Weblate ບົນ Codeberg, ໃຫ້ເພີ່ມຜູ້ໃຊ້ hosted weblate ພ້ອມດ້ວຍສິດຣີໂພຊິທໍຣີທີ່ຈຳເປັນ, ເບິ່ງ ການເຂົ້າເຖິງຄັງເກັບຈາກ Hosted Weblate.

ການແຈ້ງເຕືອນ Gitea¶

Weblate ຮອງຮັບ Gitea webhooks. ໃຫ້ເພີ່ມ Gitea Webhook ສຳລັບເຫດການ Push events ທີ່ມີປາຍທາງໄປຍັງ URL /hooks/gitea/ ບົນການຕິດຕັ້ງ Weblate ຂອງທ່ານ, ຕົວຢ່າງ https://hosted.weblate.org/hooks/gitea/. ສິ່ງນີ້ສາມາດເຮັດໄດ້ໃນ Webhooks ພາຍໃຕ້ Settings ຂອງຣີໂພຊິທໍຣີ.

See also

ການແຈ້ງເຕືອນ Forgejo¶

Weblate ຮອງຮັບ Forgejo webhooks. ໃຫ້ເພີ່ມ Forgejo Webhook ສຳລັບເຫດການ Push events ທີ່ມີປາຍທາງໄປຍັງ URL /hooks/forgejo/ ບົນການຕິດຕັ້ງ Weblate ຂອງທ່ານ, ຕົວຢ່າງ https://hosted.weblate.org/hooks/forgejo/. ສິ່ງນີ້ສາມາດເຮັດໄດ້ໃນ Webhooks ພາຍໃຕ້ Settings ຂອງຣີໂພຊິທໍຣີ.

See also

Gitea Pull request¶

Added in version 4.12.

ສິ່ງນີ້ເພີ່ມຊັ້ນບາງໆຢູ່ເທິງ Git ໂດຍໃຊ້ Gitea API ເພື່ອອະນຸຍາດໃຫ້ Push ການປ່ຽນແປງການແປເປັນ Pull request ແທນທີ່ຈະ Push ໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ.

ເພື່ອສ້າງ Pull request, ເລືອກ Gitea ເປັນ ແອັບ Weblate GitHub ແລະຕັ້ງຄ່າ GITEA_CREDENTIALS.

Bitbucket¶

ການເຂົ້າເຖິງຣີໂພຊິທໍຣີ Bitbucket¶

HTTPS ດ້ວຍ Access Token¶

SSH ດ້ວຍຜູ້ໃຊ້ສະເພາະ¶

ສຳລັບຣີໂພຊິທໍຣີ Hosted Weblate ບົນ Bitbucket, ໃຫ້ເພີ່ມຜູ້ໃຊ້ hosted weblate ພ້ອມດ້ວຍສິດຣີໂພຊິທໍຣີທີ່ຈຳເປັນ, ເບິ່ງ ການເຂົ້າເຖິງຄັງເກັບຈາກ Hosted Weblate.

ເພື່ອ Push ໂດຍກົງ, ໃຫ້ໃຊ້ Git ຫຼື Mercurial ພ້ອມກັບ URL ສຳລັບ push ຄັງເກັບ.

ການແຈ້ງເຕືອນ Bitbucket¶

Weblate ຮອງຮັບ Bitbucket webhooks. ໃຫ້ເພີ່ມ Webhook ທີ່ກະຕຸ້ນເມື່ອມີການ Push ຣີໂພຊິທໍຣີ, ທີ່ມີປາຍທາງໄປຍັງ URL /hooks/bitbucket/ ບົນການຕິດຕັ້ງ Weblate ຂອງທ່ານ, ຕົວຢ່າງ https://hosted.weblate.org/hooks/bitbucket/.

See also

Bitbucket Data Center Pull request¶

Added in version 4.16.

ສິ່ງນີ້ເພີ່ມຊັ້ນບາງໆຢູ່ເທິງ Git ໂດຍໃຊ້ Bitbucket Data Center API ເພື່ອອະນຸຍາດໃຫ້ Push ການປ່ຽນແປງການແປເປັນ Pull request ແທນທີ່ຈະ Push ໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ.

Warning

ສິ່ງນີ້ບໍ່ຮອງຮັບ Bitbucket Cloud API.

ເພື່ອສ້າງ Pull request, ເລືອກ Bitbucket Data Center ເປັນ ແອັບ Weblate GitHub ແລະຕັ້ງຄ່າ BITBUCKETSERVER_CREDENTIALS.

Bitbucket Cloud Pull request¶

Added in version 5.8.

ສິ່ງນີ້ເພີ່ມຊັ້ນບາງໆຢູ່ເທິງ Git ໂດຍໃຊ້ Bitbucket Cloud API ເພື່ອອະນຸຍາດໃຫ້ Push ການປ່ຽນແປງການແປເປັນ Pull request ແທນທີ່ຈະ Push ໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ.

Warning

ນີ້ແຕກຕ່າງຈາກ Bitbucket Data Center API.

ເພື່ອສ້າງ Pull request, ເລືອກ Bitbucket Cloud ເປັນ ແອັບ Weblate GitHub ແລະຕັ້ງຄ່າ BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

ການເຂົ້າເຖິງຣີໂພຊິທໍຣີ Azure Repos¶

HTTPS ດ້ວຍ Access Token¶

ໃຊ້ HTTPS clone URL ທີ່ສະແດງໂດຍ Azure Repos ສຳລັບຣີໂພຊິທໍຣີ.

SSH ດ້ວຍຜູ້ໃຊ້ສະເພາະ¶

ໃຊ້ SSH URL ທີ່ສະແດງໂດຍ Azure Repos ສຳລັບຣີໂພຊິທໍຣີ.

ການແຈ້ງເຕືອນ Azure Repos¶

Weblate ຮອງຮັບ Azure Repos webhooks. ໃຫ້ເພີ່ມ Webhook ສຳລັບເຫດການ Code pushed ທີ່ມີປາຍທາງໄປຍັງ URL /hooks/azure/ ບົນການຕິດຕັ້ງ Weblate ຂອງທ່ານ, ຕົວຢ່າງ https://hosted.weblate.org/hooks/azure/. ສິ່ງນີ້ສາມາດເຮັດໄດ້ໃນ Service hooks ພາຍໃຕ້ Project settings.

See also

Azure DevOps Pull request¶

ສິ່ງນີ້ເພີ່ມຊັ້ນບາງໆຢູ່ເທິງ Git ໂດຍໃຊ້ Azure DevOps API ເພື່ອອະນຸຍາດໃຫ້ Push ການປ່ຽນແປງການແປເປັນ Pull request ແທນທີ່ຈະ Push ໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ.

Git Push ການປ່ຽນແປງໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ, ໃນຂະນະທີ່ back-end Azure DevOps ຈະສ້າງ Pull request. ອັນຫຼັງບໍ່ຈຳເປັນສຳລັບການເຂົ້າເຖິງຣີໂພຊິທໍຣີ Git ພຽງຢ່າງດຽວ.

ເພື່ອສ້າງ Pull request, ເລືອກ Azure DevOps ເປັນ ແອັບ Weblate GitHub ແລະຕັ້ງຄ່າ AZURE_DEVOPS_CREDENTIALS.

Pagure¶

ການເຂົ້າເຖິງຣີໂພຊິທໍຣີ Pagure¶

HTTPS ດ້ວຍ Access Token¶

SSH ດ້ວຍຜູ້ໃຊ້ສະເພາະ¶

ການແຈ້ງເຕືອນ Pagure¶

Weblate ຮອງຮັບ Pagure hooks. ໃຫ້ເພີ່ມ Webhook ທີ່ມີປາຍທາງໄປຍັງ URL /hooks/pagure/ ບົນການຕິດຕັ້ງ Weblate ຂອງທ່ານ, ຕົວຢ່າງ https://hosted.weblate.org/hooks/pagure/. ສິ່ງນີ້ສາມາດເຮັດໄດ້ໃນ Activate Web-hooks ພາຍໃຕ້ Project options:

See also

Pagure Merge request¶

Added in version 4.3.2.

ສິ່ງນີ້ເພີ່ມຊັ້ນບາງໆຢູ່ເທິງ Git ໂດຍໃຊ້ Pagure API ເພື່ອອະນຸຍາດໃຫ້ Push ການປ່ຽນແປງການແປເປັນ Merge request ແທນທີ່ຈະ Push ໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ.

ເພື່ອສ້າງ Merge request, ເລືອກ Pagure ເປັນ ແອັບ Weblate GitHub ແລະຕັ້ງຄ່າ PAGURE_CREDENTIALS.

ຂັ້ນຕອນການເຮັດວຽກອື່ນໆ¶

ການເຂົ້າເຖິງຣີໂພຊິທໍຣີ Gitee¶

HTTPS ດ້ວຍ Access Token¶

SSH ດ້ວຍຜູ້ໃຊ້ສະເພາະ¶

ການແຈ້ງເຕືອນ Gitee¶

Weblate ຮອງຮັບ Gitee webhooks. ໃຫ້ເພີ່ມ WebHook ສຳລັບເຫດການ Push ທີ່ມີປາຍທາງໄປຍັງ URL /hooks/gitee/ ບົນການຕິດຕັ້ງ Weblate ຂອງທ່ານ, ຕົວຢ່າງ https://hosted.weblate.org/hooks/gitee/. ສິ່ງນີ້ສາມາດເຮັດໄດ້ໃນ WebHooks ພາຍໃຕ້ Management ຂອງຣີໂພຊິທໍຣີ.

See also

ຄຳຮ້ອງຂໍການກວດສອບ Gerrit¶

ການຮອງຮັບ Gerrit ເພີ່ມຊັ້ນບາງໆຢູ່ເທິງ Git ໂດຍໃຊ້ເຄື່ອງມື git-review ເພື່ອອະນຸຍາດໃຫ້ Push ການປ່ຽນແປງການແປເປັນຄຳຮ້ອງຂໍການກວດສອບ Gerrit, ແທນທີ່ຈະ Push ພວກມັນໂດຍກົງໄປຍັງຣີໂພຊິທໍຣີ.

ການຕັ້ງຄ່າ ສາຂາທີ່ຈະ push (ທາງເລືອກ) ຈະເລືອກ Branch ປາຍທາງສຳລັບການກວດສອບ Gerrit. ປ່ອຍໃຫ້ຫວ່າງໄວ້ເພື່ອໃຊ້ ບຣານຊ໌ຂອງຄັງເກັບຂໍ້ມູນ. ໃຊ້ຊື່ Branch ແບບສັ້ນ, ເຊັ່ນ main; Weblate ແລະ git-review ຈະ Push ການກວດສອບໄປຍັງ refs/for/<branch> ໂດຍອັດຕະໂນມັດ. ຕົວເລືອກ Gerrit push ສາມາດຕື່ມຕໍ່ຫຼັງ % ໃນທັງສອງການຕັ້ງຄ່າ, ຕົວຢ່າງ main%topic=l10n. Gerrit ຈະຕີຄວາມຕົວເລືອກເຫຼົ່ານີ້ເປັນບັນຊີ Weblate Gerrit ທີ່ຕັ້ງຄ່າໄວ້ ແລະນຳໃຊ້ສິດທິຂອງມັນເອງ.

ເອກະສານຂອງ Gerrit ມີລາຍລະອຽດກ່ຽວກັບການຕັ້ງຄ່າທີ່ຈຳເປັນເພື່ອຕັ້ງຄ່າຄັງເກັບໂຄ້ດດັ່ງກ່າວ. ບໍ່ມີການຕັ້ງຄ່າຂໍ້ມູນຢືນຢັນຕົວຕົນສຳລັບການຝາກໂຄ້ດແຍກຕ່າງຫາກສຳລັບລະບົບຫຼັງບ້ານ (backend) ນີ້.

ຂໍ້ມູນຢືນຢັນຕົວຕົນສຳລັບ Docker¶

ສຳລັບການຕິດຕັ້ງຜ່ານ Docker, ທ່ານສາມາດລະບຸຂໍ້ມູນຢືນຢັນຕົວຕົນຂອງ API ສຳລັບການຝາກໂຄ້ດຜ່ານຕົວປ່ຽນສະພາບແວດລ້ອມ (environment variables) ໄດ້, ເບິ່ງທີ່ ຂໍ້ມູນຢືນຢັນຕົວຕົນສຳລັບເວັບໄຊຝາກໂຄ້ດ.