Pipeline tanımı

Pipeline nerede tanımlanır?#

Bir pipeline'ı üç yerden tanımlayabilirsiniz; üçü de aynı şemayı kullanır:

• Konsolda, Delivery > Pipeline'lar altında.
• Repo'da bir dosyada, genellikle ejo.yaml. Binding'in Pipeline kaynağı alanında Repo'dan — ejo.yaml source of truth seçildiğinde EJO dosyayı bağlı branch'ten okur ve dosya değiştikçe pipeline'ı günceller.
• .ejo dosyasının pipeline: bloğunda. Bkz. .ejo dosyası.

Şema katıdır: bilinmeyen bir anahtar (usees: gibi bir yazım hatası) hata verir.

İlk pipeline#

name: web
description: Build, tara ve Kubernetes'e deploy et
steps:
  - name: Clone
    kind: GIT_CLONE
  - name: Build
    kind: KANIKO_BUILD
    config:
      dockerfile_path: Dockerfile
      registry_id: "{{.REGISTRY_ID}}"
    depends_on: [0]
  - name: Testler
    kind: SHELL
    image: node:20-alpine
    config:
      command: npm ci && npm test
    depends_on: [0]
  - name: Deploy
    kind: K8S_DEPLOY
    config:
      image: "{{.ImageTag}}"
      container_port: 3000
      wait_ready: true
      wait_seconds: 120
    depends_on: [1, 2]

Üst düzey alanlar#

Step alanları#

Sıra ve bağımlılıklar#

• depends_on hiç yazılmazsa step bir önceki step'i bekler (sıralı akış).
• depends_on: [] step'in hemen başlayabileceği anlamına gelir.
• depends_on: [1, 2] step'in 1 ve 2 numaralı step'lerin ikisini de beklemesini sağlar; bağımsız step'ler paralel çalışır.
• Döngüler ve kendine bağımlılık reddedilir.

Matrix#

- name: Test
  kind: SHELL
  image: python:3.12-slim
  matrix:
    suite: [unit, integration]
    db: [postgres, sqlite]
  config:
    command: pytest tests/{{.MatrixSuite}} --db={{.MatrixDb}}

Her kombinasyon ayrı bir step olarak çalışır. Eksen değerleri step'te {{.MatrixSuite}} ve {{.matrix_suite}} biçiminde kullanılabilir. Bir step en fazla 32 kombinasyona açılabilir. Matrix'li bir step'e bağımlı olan step, tüm kombinasyonların bitmesini bekler.

Koşullar: if ve paths#

- name: Production'a deploy
  kind: K8S_DEPLOY
  if: '{{eq .Branch "main"}}'
  paths: ["src/**", "Dockerfile"]

• if bir şablondur; sonuç true, 1 veya yes ise step çalışır, false, 0, no veya boş ise atlanır. Başka bir sonuç hata verir.
• paths GitHub Actions tarzı glob'lardır: * ve ? dizin sınırını geçmez, ** geçer. Değişen dosyalardan biri eşleşirse step çalışır. Değişen dosya listesi bilinmeyen run'larda (manuel, schedule, tag) step her zaman çalışır. EJO değişen dosya listesini yalnızca GitHub olaylarından alır; GitLab ve Azure DevOps repo'larında paths filtreli step'ler her zaman çalışır.

Cache ve artifact'lar#

- name: Build
  kind: SHELL
  image: node:20-alpine
  config:
    command: npm ci && npm run build
  cache:
    key: npm
    key_files: [package-lock.json]
    paths: [node_modules]
  artifacts:
    name: dist
    paths: [dist]
    when: on_success
    expire_in: 30d

Cache'ler agent'ın diskinde ve ayrıca master'da (remote cache) tutulur; aynı repository binding'in tüm agent'ları paylaşır. Restore önce agent'ın diskine, sonra master'a bakar. Organizasyonun cache quota'sı (varsayılan 5 GB) aşılınca en uzun süredir hit almayan girdi önce silinir; 14 gün hit almayan girdiler de silinir. pull_request run'ları branch cache'lerini okuyabilir ama yalnızca kendi pr-<numara>- key'lerine yazar; branch run'ları bu key'leri hiç restore etmez. Bir pull_request run'ı başka bir pull request'in key'lerini de okumaz; cache key ya da restore_keys girdisi pr- ile başlayamaz (pipeline kaydedilirken reddedilir, key içindeki template'ler de parse edilebilmelidir). Bir repository'nin girdilerini Cache'ler sekmesinden yönetebilirsiniz.

Artifact'lar expire_in süresini (ya da retention varsayılanını) aşınca saatlik sweeper tarafından silinir. Üç grup asla silinmez: pin'lenmiş artifact'lar (deployment'ın artifact listesindeki pin butonu), her repository binding ve pipeline için artifact'ı olan son başarılı run'ın artifact'ları ve şu anda bir production environment'a deploy edilmiş run'ın artifact'ları (orada en son başarılı run ile onun promote ettiği build). Son iki grup listede "kept" rozeti taşır. Süre dolumundan sonra sweeper ayrıca organizasyonun artifact quota'sını (Settings > Organization > Storage; boş = sınırsız, self-hosted'da varsayılan) uygular: korunmayan en eski artifact'lar önce silinir. Quota için yalnızca bitmiş run'ların en az bir saatlik artifact'ları silinir; korunan, yeni ya da bitmemiş artifact'lar toplamı quota'nın üstünde tutabilir ve yalnızca böyle veri kaldığında master warning loglar.

Image build cache#

DOCKER_BUILD ve KANIKO_BUILD, image layer'larını image'ın push edildiği registry'de tutabilir; böylece temiz bir agent'ta ya da yeni bir Kaniko pod'unda build bu layer'ları yeniden kullanır.

- name: Build image
  kind: KANIKO_BUILD
  config:
    registry_id: "..."
    cache: registry          # off | registry (true da registry demektir)
    cache_repo: registry.example.com/team/app/cache   # opsiyonel
    cache_ttl: 168h          # opsiyonel, sadece KANIKO_BUILD

KANIKO_BUILD, Kaniko'ya --cache=true --cache-repo=... --cache-ttl=... verir. DOCKER_BUILD, docker buildx build --cache-from type=registry,ref=... --cache-to type=registry,ref=...,mode=max --load kullanır. registry_id yoksa cache'i koyacak yer yoktur; docker buildx yoksa ya da agent'ın builder'ı registry cache export edemiyorsa (varsayılan docker driver'ı containerd image store ya da bir docker-container builder ister), step log'a warning yazar ve Docker daemon'ın kendi layer cache'i ile build eder. cache anahtarı yoksa DOCKER_BUILD her zaman böyle build eder.

Image cache pull_request run'ları için salt okunurdur: branch build'lerinin layer'larını yeniden kullanırlar ama hiç layer yazmazlar (KANIKO_BUILD --no-push-cache ekler, DOCKER_BUILD --cache-to'yu bırakır); böylece güvenilmeyen kod, branch build'inin güveneceği layer'lar yerleştiremez. Pipeline kaydedilirken cache, cache_ttl ve cache_repo doğrulanır.

Registry'ye özel notlar: Amazon ECR'da cache repository'sinin var olması gerekir (Kaniko için <image repository>/cache oluşturun ya da cache_repo verin); BuildKit için EJO, ECR host'larında cache export'a image-manifest=true,oci-mediatypes=true ekler. Cache layer'ları image ile aynı repository namespace'ine yazılır, yani image'ı push edebilen her credential cache'i de push edebilir. Kaniko, push kabul eden her registry ile çalışır; cache repository'si her yeni layer ile büyür, storage'a göre faturalayan registry'lerde registry'nin kendi lifecycle policy'sini tanımlayın.

Step türleri#

En sık kullanılan config anahtarları aşağıdadır. Tüm alanları konsoldaki step formunda açıklamalarıyla görebilirsiniz.

Not: DOCKER_BUILD, PODMAN_BUILD ve KANIKO_BUILD push için bir registry ister. Registry'leri Altyapı > Registry'ler altında tanımlayın ve step'te registry_id ile seçin. Otomatik SBOM ve tarama da yalnızca registry'ye push edilen image'lar için çalışır.

Değişkenler ve şablonlar#

config değerlerinde {{.Ad}} şablonları kullanabilirsiniz. Agent bunları run başladığında doldurur.

Bunlara ek olarak:

• Değişkenleriniz: Altyapı > Değişkenler altında tanımladığınız her anahtar {{.ANAHTAR}} olarak kullanılabilir. Bkz. Secret'lar ve değişkenler.
• Önceki step'lerin çıktıları: Örneğin build step'inden sonra {{.ImageTag}} ve {{.ImageDigest}}, GIT_CLONE'dan sonra {{.WorkDir}}.

Step çıktıları#

Her step türü belirli çıktılar üretir:

Bir SHELL step'i kendi çıktılarını $EJO_OUTPUT dosyasına AD=değer satırları olarak yazar ve bunları config.outputs listesinde belirtir:

- name: Versiyonu bul
  kind: SHELL
  image: alpine:3.20
  config:
    command: echo "APP_VERSION=$(cat VERSION)" >> "$EJO_OUTPUT"
    outputs: [APP_VERSION]
- name: Kullan
  kind: SHELL
  image: alpine:3.20
  config:
    command: echo "Versiyon {{.APP_VERSION}}"

WorkDir, CommitSHA veya Branch gibi sistem değişkenlerinin üzerine çıktı yazılamaz.

Manuel run girdileri#

Bir pipeline, elle başlatılan run'larda değer isteyebilir:

name: web
inputs:
  - {name: target, options: [staging, production], default: staging}
  - {name: dry_run, type: bool, default: "false"}
steps:
  - name: Göster
    kind: SHELL
    image: alpine:3.20
    config:
      command: echo "hedef=$INPUT_TARGET dry_run=$INPUT_DRY_RUN"

• Girdi alanları: name, type (string, number, bool), required, default, options, pattern, label, help.
• Değerler her step'e INPUT_<AD> environment variable'ı olarak gelir.
• Zorunlu girdiler yalnızca manuel run'larda sorulur. Push ve tag run'ları varsayılanları kullanır; schedule için her zorunlu girdinin bir varsayılanı olmalıdır.
• Girdiler açık metin saklanır, bu yüzden secret olamaz. Secret'ları değişkenlerden okuyun.

Sonraki adımlar#

• Trigger'lar ve binding'ler
• Secret'lar ve değişkenler
• Step pack'ler
• Supply chain güvenliği