Binding nedir?#
Binding, bir repo'yu bir environment'a ve bir pipeline'a bağlar. Hangi event'lerin run başlatacağı, PR'ların merge'ünün engellenip engellenmeyeceği, preview'lar ve promote hedefi binding üzerinde ayarlanır. Bir repo farklı environment'lar için birden fazla binding'e sahip olabilir.
Binding'ler GitHub, GitLab ve Azure DevOps repo'ları için aynı şekilde çalışır. Bu sayfada "pull request" (PR), GitLab'daki merge request'i de kapsar; Azure DevOps'ta da pull request denir. Konsol, GitLab binding'lerinde Merge request etiketini kullanır.
Ön koşullar#
- Bağlı bir SCM: GitHub için kurulmuş EJO Cloud GitHub App'i; GitLab ve Azure DevOps için Ayarlar > Webhook'lar'da kaydedilmiş bir webhook. Bkz. Kaynak kod bağlantısı (SCM).
- En az bir environment ve o environment'ta çalışan bir agent. Bkz. Agent kurulumu.
- En az bir pipeline. Bkz. Pipeline tanımı.
Binding oluşturma#
-
Delivery > Repo'lar sayfasında Repo bağla'ya basın.
-
Provider'ı seçin ve repo'yu girin. Alan, SCM gruplarının son taramasından öneriler gösterir; listede olmayan bir adı da yazabilirsiniz.
Provider Repo alanı Biçim GitHub GitHub repo'su owner/repo, örneğinacme/webGitLab GitLab repo'su path_with_namespace:group/projectya dagroup/subgroup/projectAzure DevOps Azure Repos repo'su org/project/repo, örneğinacme/shop/webGitLab ve Azure DevOps'ta Webhook secret'ı listesinden bu repo'yu kapsayan webhook'u seçin. GitHub App ile bağlı repo'larda bu alan gerekmez.
-
Deploy edilecek Environment'ı seçin.
-
Commit / varsayılan pipeline'ını seçin. Commit branch'ine push, manuel run, schedule ve tag run'ları bu pipeline'ı kullanır.
-
İsterseniz PR'lar için ayrı bir PR pipeline'ı seçin. Böylece PR'lar örneğin yalnızca test çalıştırırken main'e merge tam pipeline'ı çalıştırır.
.ejo dosyası olan repo'larda binding EJO tarafından da kurulabilir. Bkz. .ejo dosyası.
Pipeline kaynağı#
| Seçenek | Anlamı |
|---|---|
| Sadece UI — master source of truth | Pipeline konsolda düzenlenir ve versiyonlanır. |
| Repo'dan — ejo.yaml source of truth | Pipeline, Pipeline dosyası path'i alanındaki dosyadan okunur (örneğin ejo.yaml). Dosya değişince webhook ile senkronlanır; konsolda Publish dosyayı geri yazar. GitLab ve Azure DevOps'ta dosyayı okumak için EJO'da token tanımlı olmalıdır. |
Bir repo'yu pipeline'ın belirli bir publish edilmiş versiyonuna pin'leyebilirsiniz. Pin, pipeline'ı kullanan diğer repo'ları etkilemez.
Trigger'lar#
Binding sayfasındaki Pipeline'ı şunlarda çalıştır bölümünde hangi event'lerin run başlatacağını seçersiniz. En az bir event ya da bir schedule açık olmalıdır.
| Seçenek | Ne zaman run başlar | Varsayılan |
|---|---|---|
| Bir branch'e push | Commit branch'i'ne yapılan her push'ta. | Açık |
| Pull request (GitLab'da Merge request) | PR hedef branch'i'ni hedefleyen bir PR açıldığında, güncellendiğinde veya yeniden açıldığında. Draft PR'lar run başlatmaz. | Kapalı |
| Tag | Git tag push'u; GitHub'da ayrıca publish edilmiş bir release. | Açık |
| Schedule (opsiyonel) | UTC'de 5 alanlı cron ifadesine göre, commit branch HEAD'i üzerinde. | Boş (kapalı) |
Örneğin 0 2 * * * her gece 02:00 UTC'de çalışır. Değişiklikleri Trigger'ları kaydet ile kaydedin.
Her SCM'de bu trigger'ları besleyen olaylar:
| Trigger | GitHub | GitLab | Azure DevOps |
|---|---|---|---|
| Push | Push | Push events | Code pushed |
| Pull request | Pull request: opened, synchronize, reopened, ready for review | Merge request events: open, reopen, update | Pull request created, Pull request updated |
| Tag | Tag push, Release (published) | Tag push events | Code pushed (refs/tags/...) |
| PR kapandı | Pull request: closed | Merge request: merge, close | Pull request updated: completed, abandoned |
PR kapandığında run başlamaz; varsa preview'ı kaldırılır.
Aynı branch'e ya da PR'a yeni bir push geldiğinde, o branch için hâlâ bekleyen veya çalışan eski run'lar iptal edilir ve SUPERSEDED durumuna geçer. Aynı webhook iki kez gelirse ikinci bir deployment oluşmaz.
Manuel run#
Binding sayfasındaki Run butonu pipeline'ı elle başlatır. SHA (opsiyonel) boş bırakılırsa commit branch'inin HEAD'i kullanılır. Pipeline'da inputs tanımlıysa Run parametreleri formunda değerler sorulur. Bkz. Pipeline tanımı.
Fork'tan gelen PR'lar#
Fork'tan açılan PR'larda (üç SCM'de de):
- Fork'taki
ejo.yamlkullanılmaz; binding'in kayıtlı pipeline'ı çalışır. SECRET,K8S_SECRETveEXTERNAL_SECRETdeğerleri ve clone kimlik bilgileri verilmez.- Pipeline OIDC token'ları üretilmez ve otomatik supply chain taraması atlanır.
Merge gate#
Bu pipeline başarılı olana kadar merge'ü engelle açıkken PR pipeline'ı bir merge gate olur. Bu seçenek PR trigger'ını da açar.
Ana (commit) pipeline, merge edilen commit'in PR pipeline'ı başarılı olana kadar WAITING durumunda kalır. Bu bekleme her SCM'de EJO tarafında çalışır. EJO ayrıca merge butonunu SCM tarafında da engeller:
| SCM | EJO ne yapar | Gereken yetki |
|---|---|---|
| GitHub | PR hedef branch'i için ejo status'ünü zorunlu kılan bir ruleset ekler. GitHub Free planındaki private repo'larda ruleset olmadığından merge butonu engellenmeyebilir. |
GitHub App'in Administration izni |
| GitLab | Projede Pipelines must succeed (only_allow_merge_if_pipeline_succeeds) ayarını açar. Proje geneli bir ayardır; merge gate kapatılınca geri alınmaz. |
api scope'lu token |
| Azure DevOps | PR hedef branch'inde engelleyici bir Status branch policy'si oluşturur (genre ejo, name pipeline); merge gate kapatılınca siler. |
PAT'te Code (Read & write), Code (Status), Policy (Read & write) |
GitLab token'ı ya da Azure DevOps PAT'i hiç tanımlı değilse merge gate açılamaz; binding kaydedilirken hata verir. Yetki yetmezse SCM tarafındaki ayar yapılmaz ama EJO tarafındaki bekleme yine çalışır. Ayrıntılar: Kaynak kod bağlantısı (SCM).
Merge gate ile birlikte kullanılabilecek seçenekler:
| Seçenek | Ne yapar |
|---|---|
| Gereken GitHub onaylayan review sayısı | GitHub ruleset'ine eklenir. 0 yalnızca status check'i bırakır, en fazla 6. Yalnızca GitHub. |
| Review App URL'ini de bekle | Merge gate, PR run'ının bir preview URL'i olana kadar bekler. GitHub ruleset'i ayrıca ejo/preview status'ünü ister; Azure DevOps'ta name preview için ikinci bir status policy eklenir; GitLab'da bekleme yalnızca EJO tarafındadır. |
| PR pipeline'ında bir güvenlik scan step'i (Trivy veya Sonar) iste | Pipeline'da TRIVY_SCAN veya SONAR_SCAN step'i yoksa ya da hepsi atlanırsa PR run'ı fail olur. |
| Bu servisin sunduğu bir API'yi bozan pull request'leri engelle | .ejo içindeki provides spec'i hedef branch ile karşılaştırılır. Kaldırılan bir operasyon veya yeni bir zorunlu parametre ejo status'ünü fail eder. Yalnızca GitHub. |
Uyarı: Review App URL'ini de bekle için hedef environment'ta bir preview domain'i gerekir; yoksa merge gate sonsuza kadar bekler. Bkz. Preview'lar.
Preview'lar#
PR'da preview (izole isim, PR kapanınca kaldırılır) açıkken her PR kendi izole adıyla deploy edilir ve PR kapanınca kaldırılır. Preview label (opsiyonel) ile yalnızca belirli label'ı taşıyan PR'lar preview alır (GitHub ve GitLab; Azure DevOps label'ları yok sayar); Preview health path (opsiyonel) preview'ın hazır sayılması için istek atılan yoldur. Ayrıntılar: Preview'lar.
Promote#
Başarılı bir run, Promote ile aynı commit SHA'sı üzerinden başka bir environment'a taşınabilir.
- Promote hedefi: varsayılan hedef environment. Bağlı environment ile aynı olamaz. Boş bırakılırsa hedef promote anında seçilir.
- Promote pipeline'ı: hedefte çalışacak pipeline. Boş bırakılırsa ve hedef Kubernetes ise EJO kayıtlı image digest'ini yeniden build etmeden deploy eder.
- Başarılı bir commit veya manuel run'dan sonra otomatik promote: başarılı commit ve manuel run'lardan sonra promote'u kendiliğinden başlatır. Promote run'ları kendileri tekrar promote edilmez.
Diğer seçenekler#
- Fail olunca debug: Bir step fail olduğunda agent container'ı etkileşimli bir debug oturumu için açık tutar. Bkz. Deploy verification ve rollback.
- Dependency'ler: Bir binding'i başka bir repo'nun en son başarılı run'ını bekleyecek şekilde ayarlayabilirsiniz. Aynı commit SHA'sını bekle açıkken aynı commit beklenir; kapalıyken dependency branch'indeki en son başarı yeterlidir.