CI hattı ve sürüm

Cluster ERP'nin sürekli tümleştirmesi tek bir GitHub Actions iş akışıdır: .github/workflows/ci.yml. Her push ve pull request için üç kapı işi koşar ve sürüm etiketleri için bir dağıtım işi ekler. Bu sayfa her işi, aralarındaki sırayı ve etiketler ile CHANGELOG.md kurallarını açıklar. Bir etiketin ardından staging'den nasıl geçtiği ortamlar ve terfi sayfasındadır.

Kısaca¶

• Tetikleyiciler: herhangi bir dala push, v* kalıbına uyan bir etiketin push'u ve her pull request (.github/workflows/ci.yml:25-29).
• Üç kapı işi paralel koşar: lint, lock ve test (.github/workflows/ci.yml:37-124).
• deploy işi yalnız refs/tags/v* için ve yalnız üç kapının hepsi geçtikten sonra koşar (.github/workflows/ci.yml:126-129).
• İş akışı jetonu yalnız depo içeriğini okuma yetkisine sahiptir (.github/workflows/ci.yml:31-32).
• Her iş Python paketlerini requirements.lock dosyasından --require-hashes ile kurar (.github/workflows/ci.yml:47, .github/workflows/ci.yml:106).

Nasıl çalışır¶

İş grafiği:

flowchart LR
  push["push veya pull request"] --> lint["lint: ruff + mypy"]
  push --> lock["lock: kilit bütünlüğü + duyurular"]
  push --> test["test: göçler + pytest"]
  lint --> deploy["deploy: yalnız v* etiketi"]
  lock --> deploy
  test --> deploy
  deploy --> node["install.sh --role production"]

Düz yazıyla: üç kapı her olayda birlikte başlar; dağıtım işi üçünü de bekler ve yalnız bir sürüm etiketi için koşar; ardından üretim düğümünde kurucuyu çağırır.

Lint işi¶

Kilitli paketleri, projeyi, dev ekini ve PySide6==6.8.3 paketini kurar, ardından ruff check src tests ve mypy src koşar (.github/workflows/ci.yml:38-52). mypy src Qt istemcisini de denetlediği için masaüstü araç takımı kurulur (.github/workflows/ci.yml:48-49).

Lock işi¶

1. uv lock --check, uv.lock dosyası pyproject.toml ile eşleşmediğinde başarısız olur (.github/workflows/ci.yml:59-62).
2. İş requirements.lock dosyasını aynı komutla yeniden dışa aktarır ve en küçük farkta başarısız olur (.github/workflows/ci.yml:63-68).
3. pip-audit, requirements.lock içindeki her sürümü katı kipte denetler; bilinen bir güvenlik duyurusu olan sürüm işi başarısız kılar (.github/workflows/ci.yml:72-74).

[tool.uv] içindeki sabitlemeler, tam bataryanın ve pytest'in en son koştuğu sürümlerdir; açıklama birinin nasıl taşınacağını anlatır (pyproject.toml:155-166).

Test işi¶

İş bir postgres:16 servis konteyneri başlatır ve veritabanı ayarlarını ve yalnız CI'a ait bir gizli anahtarı iş ortamı üzerinden geçirir (.github/workflows/ci.yml:79-99). Değerler güvenlik açıklama politikası gereği yazılmamıştır. Ardından:

1. bütün Alembic geçmişini boş veritabanına uygular (.github/workflows/ci.yml:110-113);
2. tam olarak bir Alembic başı yoksa başarısız olur (.github/workflows/ci.yml:114-117);
3. pytest koşar (.github/workflows/ci.yml:124).

CLUSTER_SKIP_LIVE_TESTS=1, çalışan bir sunucu isteyen testleri atlar; böylece bu muafiyet görünür olur (.github/workflows/ci.yml:17-20, .github/workflows/ci.yml:99).

Dağıtım işi¶

İş GitHub production ortamını kullanır ve production-deploy eşzamanlılık grubu koşan bir dağıtımı hiç iptal etmez (.github/workflows/ci.yml:131-136). Adlarıyla DEPLOY_HOST, DEPLOY_USER, DEPLOY_SSH_KEY, DEPLOY_HOST_KEY ve DEPLOY_DOMAIN olmak üzere dört gizli değer ve bir değişken ister ve biri boşsa durur (.github/workflows/ci.yml:139-150). Düğümün ana makine anahtarı bir gizli değerden gelir ve katı biçimde denetlenir (.github/workflows/ci.yml:153-155). İş düğümde install.sh --tag <tag> --domain <domain> --role production koşar (.github/workflows/ci.yml:155-156); böylece kurucunun terfi kapısı uygulanır (deploy/install.sh:101-107).

Neden böyle kurulmuştur¶

• Göç adımı Linux PostgreSQL üzerinde koşar, çünkü burası "the first place a Windows-authored migration meets Linux PostgreSQL" (.github/workflows/ci.yml:110-112).
• "a drifted lock means somebody edited one without the other" (.github/workflows/ci.yml:60-61).
• "a pin with a known advisory does not ship" (.github/workflows/ci.yml:73).
• Dağıtım işi production ortamında onay ister; böylece "a tag alone never reaches a customer node" (.github/workflows/ci.yml:7-12).

Kurallar ve sınırlar¶

• Sürüm etiketleri v<version> biçimindedir; terfi kaydı staging-ok/v<version> biçimindedir (.github/workflows/ci.yml:28, deploy/install.sh:15-21).
• CHANGELOG.md, Keep a Changelog ve Anlamsal Sürümleme kurallarını izler; bir [Unreleased] bölümüyle açılır ve her sürümün Added, Changed ve Fixed gibi gruplarla [<version>] - <date> başlığı vardır (CHANGELOG.md:1-14).
• "Every production deployment names the tag it ships; a tag is never moved." (CHANGELOG.md:8).
• ruff ve mypy sürümleri dev ekinde sabitlenmiştir; böylece CI iş istasyonuyla aynı araçlarla değerlendirir (pyproject.toml:75-84). Bkz. lint ve tür denetimi.

Diğer parçalarla etkileşim¶

• Tarayıcı bataryası iş akışının parçası değildir; terfi etiketi atılmadan önce staging düğümünde koşar (.github/workflows/ci.yml:21-22). Bkz. E2E bataryası.
• Python testleri Python testleri sayfasında açıklanır.

Sınırlar ve açık noktalar¶

• alembic check bir kapı değildir; açıklama migrations/env.py içindeki model meta verisinin eksik olduğunu anlatır (.github/workflows/ci.yml:118-123).
• production ortamının gerçekten zorunlu onaylayıcıları olup olmadığı bir depo ayarıdır: Koddan belirlenemedi. Yalnız iş akışının başlık açıklaması incelendi (.github/workflows/ci.yml:7-12).

Tanıtılan terimler¶

İlgili sayfalar¶

• İşletim
• Ortamlar ve terfi
• Veritabanı göçleri
• Lint ve tür denetimi

92f8051 numaralı commit ile 2026-11-13 tarihinde doğrulandı.