Kaynak kod bağlantısı (SCM)

Genel bakış#

EJO üç SCM ile çalışır: GitHub, GitLab ve Azure DevOps. Bir organizasyonda üçünü aynı anda kullanabilirsiniz; her repo binding'i kendi SCM'sini seçer. Bağlantı kurulduktan sonra EJO:

• repo'ları agent'ta clone etmek için kimlik bilgisi verir,
• push, pull request (GitLab'da merge request) ve tag olaylarını alıp run başlatır,
• commit'lere ve pull request'lere ejo status'ü ve bir yorum yazar,
• isterseniz merge gate'i SCM tarafında da uygular,
• SCM gruplarını tarayıp .ejo dosyalarını okur ve binding formunda repo aramasını doldurur.

Üç SCM aynı işleri yapar, ama bağlanma şekilleri farklıdır:

Not: Binding formundaki repo araması SCM'ye canlı sorgu atmaz; SCM gruplarının son taramasından gelir. Ayarlar > Webhook'lar'da bir webhook kaydettiğinizde, kapsadığı GitHub organizasyonu, GitLab grubu veya Azure DevOps projesi SCM grubu olarak eklenir ve taranır. Aramada çıkmayan bir repo'nun adını elle de yazabilirsiniz.

GitHub#

EJO Cloud'da her müşteri kendi GitHub App'ini oluşturmaz. Tek, paylaşılan bir EJO Cloud GitHub App'i vardır: onu kendi GitHub hesabınıza veya organizasyonunuza kurar ve kurulum sırasında hangi repo'ları görebileceğini seçersiniz. Bu akış yalnızca GitHub içindir.

Bağlantı kurulduktan sonra:

• Agent'lar private repo'larınızı kısa ömürlü, yalnızca seçtiğiniz repo'larla sınırlı installation token'larıyla clone eder.
• GitHub olayları (push, pull request, release) EJO'ya kendiliğinden ulaşır. Repo'larınızda elle webhook tanımlamanız gerekmez.
• EJO commit'lere ejo status'ü yazar, pull request'lere yorum ekler ve isterseniz merge gate için ruleset yönetir.

Not: GitHub bağlı değilken agent'lar yalnızca public GitHub repo'larını clone edebilir ve commit status'leri gönderilmez.

Ön koşullar#

• EJO organizasyonunuzda admin rolü.
• GitHub'da uygulamayı kurmak istediğiniz hesapta veya organizasyonda uygulama kurma yetkisi. Organizasyonlarda bu genellikle organizasyon sahibidir.

Bağlama#

1. Konsolda Ayarlar > GitHub App sayfasını açın.
2. EJO'yu GitHub'a install et butonuna basın. GitHub'a yönlendirilirsiniz.
3. EJO Cloud uygulamasını kuracağınız hesabı veya organizasyonu seçin.
4. Erişim için All repositories ya da yalnızca seçtiğiniz repo'ları işaretleyip kurulumu onaylayın. GitHub ayrıca hesabınızla yetkilendirme ister; bu, EJO'nun kurulumun gerçekten size ait olduğunu doğrulaması içindir.
5. GitHub sizi ejocloud.com'daki onay sayfasına getirir: "GitHub hesabı bağlansın mı?" Sayfada GitHub hesap adı ve EJO organizasyonunuzun adı yazar.
6. Bilgiler doğruysa Bağla'ya basın. Konsoldaki Ayarlar > GitHub App sayfasına dönersiniz ve "GitHub App bağlandı" mesajını görürsünüz.

Uyarı: Onay sayfası, başkasının size gönderdiği bir kurulum bağlantısıyla hesabınızın yanlış bir organizasyona bağlanmasını önlemek için vardır. Organizasyon adını tanımıyorsanız İptal'e basın. Onay sayfası 10 dakika geçerlidir.

İstenen izinler#

Uygulamanın dinlediği olaylar: Push, Pull request, Pull request review ve Release.

Merge gate#

Binding'de Bu pipeline başarılı olana kadar merge'ü engelle açıksa EJO, PR hedef branch'i için ejo status'ünü zorunlu kılan bir ruleset ekler. Gereken GitHub onaylayan review sayısı aynı ruleset'e eklenir; Review App URL'ini de bekle açıksa ejo/preview status'ü de zorunlu olur. GitHub Free planındaki private repo'larda ruleset olmadığından merge butonu engellenmeyebilir; ana pipeline yine de WAITING kalır.

Repo erişimini değiştirme#

Hangi repo'ların görüleceğini sonradan GitHub'da, kurulu uygulamanın ayarlarından değiştirebilirsiniz. EJO her işlem için token'ı o anki kuruluma göre aldığı için ayrıca bir şey yapmanız gerekmez.

Bağlantıyı kaldırma#

Ayarlar > GitHub App sayfasında Bağlantıyı kes'e basın. Bu işlem EJO uygulamasını o GitHub hesabından kaldırır; webhook'lar ve status check'ler yeniden kurana kadar durur. Uygulamayı GitHub tarafından kaldırırsanız EJO bunu da algılar ve bağlantıyı siler.

Her EJO organizasyonu aynı anda tek bir GitHub kurulumuna bağlanabilir. Başka bir hesaba geçmek için önce mevcut bağlantıyı kesin.

Sık görülen hatalar#

GitLab#

GitLab'da paylaşılan bir uygulama yoktur. EJO, GitLab'a bir personal access token ile bağlanır; olaylar proje webhook'larıyla gelir. Varsayılan GitLab adresi https://gitlab.com'dur.

Ön koşullar#

• EJO organizasyonunuzda admin rolü (Ayarlar > Webhook'lar sayfası admin'e açıktır).
• api ve read_repository scope'larına sahip bir GitLab personal access token'ı. EJO bu token'ı clone URL'lerinde, commit status'lerinde, merge request note'larında, merge request aramasında, webhook oluştururken ve merge gate ayarında kullanır.
• Token sahibinin projede webhook ekleyip proje ayarını değiştirebilmesi. GitLab bunun için projede en az Maintainer rolü ister.

Uyarı: EJO Cloud konsolunda GitLab token'ı girilecek bir alan henüz yoktur. Token, EJO'nuzun sunucu ayarında (gitlab.token) tutulur; self-managed bir GitLab kullanıyorsanız adresi de (gitlab.base_url) orada tanımlanır. Tanımlatmak için Destek sayfasındaki adresten bize yazın ve talebinize token'ın kendisini eklemeyin. Self-managed GitLab'ın EJO Cloud'dan internet üzerinden erişilebilir olması gerekir.

Token tanımlı değilken EJO yalnızca public repo'ları clone eder; commit status'ü, merge request note'u, SCM grubu taraması, .ejo okuma ve merge gate çalışmaz. Webhook'lar ve run'lar yine çalışır.

Bağlama#

1. Ayarlar > Webhook'lar sayfasında Yeni webhook'a basın.
2. Ad alanına bir ad verin, Provider olarak GitLab'ı seçin.
3. Proje alanına projenin path_with_namespace değerini girin, örneğin acme/web ya da acme/platform/web. GitLab'da her webhook tek bir projeyi kapsar.
4. Secret alanını boş bırakırsanız EJO bir secret üretir. Secret şifreli saklanır.
5. Hook'u SCM'de şimdi oluştur kutusu işaretliyken kaydedin. Token tanımlıysa EJO, GitLab'da projeye webhook'u kendisi ekler.
6. Kaydettiğinizde form yerine Delivery URL'i, Header / secret alanı (X-Gitlab-Token) ve Secret görünür. Secret'ı şimdi kopyalayın; EJO onu bir daha göstermez.
7. Hook otomatik oluşturulduysa sayfada "SCM'de oluşturuldu" yazar. Oluşturulamadıysa "Hook SCM'de oluşturulamadı" uyarısı çıkar; webhook'u aşağıdaki gibi elle ekleyin.
8. Delivery > Repo'lar > Repo bağla ile binding oluşturun: Provider olarak GitLab'ı seçin, GitLab repo'su alanına group/project girin ve Webhook secret'ı listesinden az önce kaydettiğiniz webhook'u seçin.

Webhook'u elle ekleme#

GitLab'da projenin Settings > Webhooks sayfasında yeni bir webhook ekleyin:

Webhook'u kaydettikten sonra GitLab'daki Test ile bir push olayı gönderip Recent events listesinde cevabı kontrol edin.

Status ve merge request yorumları#

EJO her run için commit'e ejo adlı bir commit status'ü yazar; preview'ı olan merge request run'larında ayrıca ejo/preview, promote ve rollback run'larında ejo/promote ve ejo/rollback yazar. Merge request run'larının sonucu merge request'e bir note olarak eklenir ve her push'ta güncellenir.

Merge gate#

Binding'de Bu pipeline başarılı olana kadar merge'ü engelle açıksa EJO, GitLab projesinde Pipelines must succeed ayarını (only_allow_merge_if_pipeline_succeeds) açar. EJO'nun commit status'leri GitLab'da harici bir pipeline olarak göründüğü için merge, ejo başarılı olana kadar engellenir. Ana (commit) pipeline da merge request pipeline'ı başarılı olana kadar WAITING kalır.

• Bu ayar proje genelidir. Merge gate'i kapattığınızda EJO ayarı geri almaz, çünkü EJO'dan önce de açık olabilir.
• Token'da api scope'u yoksa ya da yetki yetmezse ayar yapılmaz; EJO tarafındaki WAITING gate yine çalışır. Bu durumda GitLab'da Pipelines must succeed ayarını elle açın.
• Token hiç tanımlı değilse binding kaydedilirken merge gate reddedilir.
• Review App URL'ini de bekle için EJO GitLab'da ayrı bir ayar yapmaz; bekleme EJO tarafında olur.

Sık görülen hatalar#

Azure DevOps#

Azure DevOps'ta da paylaşılan bir uygulama yoktur. EJO, Azure DevOps'a bir personal access token (PAT) ile bağlanır; olaylar service hook'larla gelir. EJO dev.azure.com üzerindeki Azure DevOps Services ile çalışır; kendi sunucunuzda çalışan Azure DevOps Server desteklenmez.

Ön koşullar#

• EJO organizasyonunuzda admin rolü.
• Bir Azure DevOps PAT'i. Clone ve status için en az Code (Read) ve Code (Status) gerekir. Merge gate'in branch policy'lerini EJO'nun kendisinin kurması için Code (Read & write), Code (Status) ve Policy (Read & write) verin.

Uyarı: EJO Cloud konsolunda Azure DevOps PAT'i girilecek bir alan henüz yoktur. PAT, EJO'nuzun sunucu ayarında (azure_devops.pat) tutulur. Tanımlatmak için Destek sayfasındaki adresten bize yazın ve talebinize PAT'in kendisini eklemeyin.

PAT tanımlı değilken EJO yalnızca public repo'ları clone eder; commit ve pull request status'ü, pull request yorumu, SCM grubu taraması, .ejo okuma ve merge gate çalışmaz. Webhook'lar ve run'lar yine çalışır.

Bağlama#

1. Ayarlar > Webhook'lar sayfasında Yeni webhook'a basın.
2. Ad alanına bir ad verin, Provider olarak Azure DevOps'u seçin.
3. Proje alanına org/project (o projedeki tüm repo'lar) ya da org/project/repo girin.
4. Secret alanını boş bırakırsanız EJO bir secret üretir.
5. Hook'u SCM'de şimdi oluştur kutusu işaretliyken kaydedin. PAT tanımlıysa EJO projede üç service hook subscription'ı oluşturur: Code pushed, Pull request created ve Pull request updated.
6. Kaydettiğinizde form yerine Delivery URL'i, Header / secret alanı (X-Ejo-Webhook-Secret) ve Secret görünür. Secret'ı şimdi kopyalayın.
7. Service hook'lar oluşturulamadıysa "Hook SCM'de oluşturulamadı" uyarısı çıkar; aşağıdaki gibi elle ekleyin.
8. Delivery > Repo'lar > Repo bağla ile binding oluşturun: Provider olarak Azure DevOps'u seçin, Azure Repos repo'su alanına org/project/repo girin ve Webhook secret'ı listesinden webhook'u seçin.

Service hook'ları elle ekleme#

Azure DevOps'ta Project Settings > Service hooks sayfasında Web Hooks tipinde her olay için ayrı bir subscription oluşturun:

Pull request'in tamamlanması veya bırakılması Pull request updated olayıyla gelir; preview'lar bu olayla kaldırılır.

Status ve pull request yorumları#

EJO her run için aynı status'ü hem commit'e hem pull request'e yazar: genre ejo, name pipeline. Preview'ı olan pull request run'larında name preview, promote ve rollback run'larında promote ve rollback kullanılır. Pull request run'larının sonucu pull request'e bir thread olarak eklenir ve her push'ta güncellenir.

Merge gate#

Binding'de Bu pipeline başarılı olana kadar merge'ü engelle açıksa EJO, PR hedef branch'inde engelleyici bir Status branch policy'si oluşturur: genre ejo, name pipeline. Review App URL'ini de bekle açıksa name preview için ikinci bir policy ekler; bu seçeneği kapattığınızda o policy silinir. Merge gate'i kapattığınızda EJO iki policy'yi de siler. Ana (commit) pipeline da pull request pipeline'ı başarılı olana kadar WAITING kalır.

• PAT'te Policy (Read & write) yoksa policy oluşturulamaz; EJO tarafındaki WAITING gate yine çalışır. Bu durumda hedef branch'e genre ejo, name pipeline status'ünü isteyen bir branch policy'yi elle ekleyin.
• PAT hiç tanımlı değilse binding kaydedilirken merge gate reddedilir.

Sık görülen hatalar#

Sonraki adımlar#

• Agent kurulumu
• Trigger'lar ve binding'ler
• Sorun giderme