Kendi sunucunuzda barındırılan Git sağlayıcıları

Bir işi işaret eden bir tanımlayıcıyı dal adında veya başlığında taşıyan ya da gövdede bir kapanış anahtar kelimesinden sonra geçiren pull/merge request'lerin o işe otomatik bağlanması, birleştirildiklerinde işi çalışma alanının seçtiği duruma taşıması ve CI durumunu göstermesi için çalışma alanı başına kendi sunucunuzda barındırılan bir Forgejo, Gitea veya GitLab örneği bağlayın.

Yalnızca kendi sunucunuzda barındırılan Multica. Bu entegrasyon yalnızca Multica'yı kendiniz çalıştırdığınızda kullanılabilir; Multica Cloud'da sunulmaz. Buradaki "kendi sunucunuzda barındırma", Multica'nın kendi sunucunuzda barındırıldığı anlamına gelir — tipik olarak kendi ağınızdaki bir Git örneğine ulaşabilmesi için. Bir sunucu operatörünün bunu etkinleştirmesi (MULTICA_VCS_INTEGRATION_ENABLED=true) ve MULTICA_VCS_SECRET_KEY'i ayarlaması gerekir; bu yapılana kadar bölüm Ayarlar → Kod'da görünmez.

Multica, çalışma alanı başına kendi sunucunuzda barındırılan bir Git sağlayıcısına bağlanır: Forgejo, Gitea veya GitLab. Bağlandıktan sonra, dal adında veya başlığında bir iş tanımlayıcısı içeren (örneğin MUL-123) ya da gövdesinde bir kapanış anahtar kelimesinden sonra bir tanımlayıcı geçen (Closes MUL-123) herhangi bir pull request (GitLab'da: merge request), o işe otomatik bağlanır ve iş kenar çubuğunda Pull request'ler altında görünür. İşe bağlı her PR birleştirildiğinde, iş çalışma alanının seçtiği duruma (varsayılan olarak Bitti) taşınır. Head commit için CI, kart üzerinde bir kontroller çubuğu olarak görünür.

Bu sağlayıcılar GitHub'la birlikte çalışır: bir çalışma alanı herhangi bir kombinasyonu kullanabilir.

GitHub'ın aksine, bu sağlayıcıların bir "App" modeli yoktur. Her çalışma alanı kendi örnek URL'sini artı bir erişim token'ını saklar ve deposunda veya organizasyonunda bir webhook kaydeder. Token ve webhook sırrı, saklanırken şifrelenir.

Ön koşullar (sunucu)

Bu dağıtım için entegrasyonu açın. Varsayılan olarak kapalıdır, bu yüzden şunu ayarlayana kadar bölüm gizli kalır:

MULTICA_VCS_INTEGRATION_ENABLED=true

Resmi kendi sunucunuzda barındırma docker compose dosyası (docker-compose.selfhost.yml) bunu sizin için ayarlar.

Sonra, sunucunun saklanan kimlik bilgilerini şifreleyebilmesi için base64 kodlu 32 baytlık bir anahtar ayarlayın. Bu olmadan, bağlantı formu devre dışıdır.

openssl rand -base64 32

MULTICA_VCS_SECRET_KEY=<base64 32-byte key>

İkisi de zorunludur: anahtar özelliğin sunulup sunulmadığına karar verir, gizli anahtar ise saklanan token'ı ve webhook sırrını şifreler. Bağlama, webhook ve döndürme işlemlerinin hepsi ikisini de gerektirir.

Multica'nın yapıştırmaya hazır bir webhook URL'si gösterebilmesi için MULTICA_PUBLIC_URL'i sunucunun herkese açık taban URL'sine ayarlayın. Bu olmadan, arayüz yalnızca webhook yolunu gösterir ve kendi kaynağınızı siz eklersiniz.

Bir çalışma alanı bağlama

Sağlayıcınızda, yansıtmak istediğiniz depolara okuma erişimi olan bir erişim token'ı oluşturun:
- Forgejo / Gitea: Settings → Applications.
- GitLab: read_api kapsamına sahip bir kişisel (veya grup/proje) erişim token'ı.
Multica'da Ayarlar → Kod'u açın, ardından Kendi sunucunuzdaki Git satırında Bağlan'a tıklayın.
Sağlayıcıyı seçin, örnek URL'sini (örneğin https://forgejo.example.com) ve erişim token'ını girin, sonra Bağlan'a tıklayın. Multica, kaydetmeden önce token'ı örneğe karşı doğrular.
Bağlandıktan sonra gösterilen webhook URL'sini ve webhook sırrını kopyalayın.

Webhook sırrı yalnızca bir kez gösterilir. Sayfadan ayrılmadan önce kopyalayın. Aynı örneği yeniden bağlamak token'ı ve sırrı döndürür.

Özel CA'lı örnek

Bağlan, sağlayıcının sertifikasının "is signed by a certificate authority this server does not trust" olduğunu bildirirse, örneğin HTTPS sertifikası Multica sunucusunun güvenmediği bir iç CA'dan geliyordur (veya kendinden imzalıdır). Bir sunucu operatörü bu CA'yı backend'in güven deposuna ekler: Helm ile backend.extraCACerts.configMap'i ayarlayın; Docker Compose ile CA'yı bağlayın ve SSL_CERT_DIR'i ayarlayın. Adımlar için Özel CA sertifikaları bölümüne bakın.

Bağlantı isteği erişim token'ınızı taşıdığı için Multica'da sertifika doğrulamasını atlama seçeneği yoktur. Mesaj sertifikanın ana makine adıyla eşleşmediğini veya doğrulamadan geçemediğini (örneğin süresinin dolduğunu) söylüyorsa, sertifikanın kendisini düzeltin; CA'ya güvenmek işe yaramaz.

Webhook'u kaydetme

Depoda (veya her depoyu kapsayacak şekilde organizasyonda/grupta):

Forgejo / Gitea — Settings → Webhooks → Add Webhook → Forgejo/Gitea:

Target URL: bir önceki adımdaki webhook URL'si.
HTTP method POST, content type application/json.
Secret: webhook sırrı (X-Gitea-Signature HMAC'ini doğrulamak için kullanılır).
Trigger events: Pull Request'i ve CI'ı yansıtmak için Commit Status'ü seçin.

GitLab — Settings → Webhooks:

URL: webhook URL'si.
Secret token: webhook sırrı (X-Gitlab-Token olarak gönderilir ve birebir karşılaştırılır).
Triggers: Merge request events'i ve CI'ı yansıtmak için Pipeline events'i etkinleştirin.

Multica, her teslimatı saklanan sırra karşı doğrular, bu yüzden eşleşen sırrı olmayan bir webhook reddedilir.

Neler yansıtılır

Pull / merge request'ler — açık, kapalı, birleştirilmiş ve taslak durumu, yazar, dal ve (sağlayıcı sağladığında) diff istatistikleri.
İş bağlantıları — başlıktaki veya daldaki bir tanımlayıcı PR'ı işe bağlar, gövdede bir kapanış anahtar kelimesinden sonra gelen bir tanımlayıcı da öyle; gövdedeki çıplak bir bahsetme hiçbir şeyi bağlamaz. İşe bağlı her PR — GitHub ve kendi sunucunuzdaki sağlayıcılar genelinde — birleştirildiğinde, iş GitHub ile aynı ayar ve kurallar altında çalışma alanının seçtiği duruma taşınır. Bir sağlayıcı bağlandıktan sonra bu sayfa aynı PR'lar birleştikten sonra işi şuraya taşı ayarını gösterir.
CI — Forgejo/Gitea commit durumları ve GitLab pipeline'ları, head commit için geçti/başarısız/beklemede bir kontroller çubuğunda toplanır.

Agent'ların pull request açması

PR oluşturmak Multica'da hiçbir sağlayıcı yapılandırması gerektirmez. Agent'lar depoları runtime'da checkout eder ve dal push edip PR açmak için runtime host'unun kendi Git kimlik bilgilerini kullanır. Agent'ların bir sağlayıcıya karşı çalışmasına izin vermek için, daemon host'unun ona kimlik doğrulayabildiğinden emin olun — örneğin bir SSH deploy key veya host'un Git kimlik bilgisi yardımcısındaki bir token — ve depo URL'sini her zamanki gibi ekleyin. Depo checkout'u herhangi bir Git URL'siyle çalışır, bu yüzden sağlayıcıya özel bir bağlantı gerekmez.