Git ile çalışma ve kendi deponuzu bağlama

Git, entegrasyon kaynaklarının değişiklik geçmişini ve dağıtılacak sürümünü tutar. Lunex bir kurulum için yapılandırılmış ortak depoyu ve dalı kullanır; her proje bu depoda kendi dizininde yer alır. Kullanıcının oturum açması Git hesabını otomatik bağlamaz. Git erişim hesabını kurulum yöneticisi, commit yazarı bilgisini ise kullanıcının kimlik hesabı belirler.

Kaydetme, commit ve çalıştırma arasındaki fark

Git’e gönderilmeyen bir düzeltme Run sırasında görünüp Build sonucunda görünmeyebilir. Bu durumda önce Source farkını ve Last commit bilgisini kontrol edin.

Değişiklikleri commit edip gönderme

Ön koşullar: platform-developer rolü, geliştirme ortamı, Git’e yazabilen kurulum hesabı ve kimlik hesabınızda dolu bir e-posta alanı. Diğer kurulumlarda Push (n) devre dışıdır ve sunucu commit isteğini reddeder.

1. Dosyaları düzenleyin ve kaydetmenin tamamlanmasını bekleyin.
2. Source → Files açın. Değişiklik durumuna tıklayarak kaydedilmiş dosya ile son commit arasındaki farkı inceleyin.
3. Göndermek istediğiniz dosyaların seçim kutularını işaretleyin. Dosya silmelerini de kontrol edin: push sırasında projede silinmiş dosyalar Git indeksine alınır.
4. Push (n) seçin.
5. Commit message alanına değişikliğin amacını yazın; örneğin Validate order number before queue delivery.
6. Commit and push seçin; bildirimi ve Last commit bilgisini kontrol edin.
7. Source → Commits açın. Yeni commit’in zamanı, yazarı, mesajı ve dosya farklarının beklediğiniz gibi olduğunu doğrulayın.

Bu örnekte bir dosya seçilmiştir; Push (1) sonraki adımda commit penceresini açar. Not committed, dosyanın kaydedildiğini fakat henüz Git’e gönderilmediğini gösterir. Görsel dosya seçimi aşamasıdır; başarılı push sonucu değildir.

Git sunucusuna erişim, kurulumun ortak erişim bilgileriyle gerçekleşir; commit yazarı hesabınızın doğrulanmış kullanıcı adı ve e-posta bilgisidir. Configure an email address in your account before committing to Git. hatası alırsanız kimlik hesabının e-posta alanını tamamlayıp yeniden oturum açın.

Git’ten güncel içeriği alma

Bir projenin güncel dosyaları için Source → Pull kullanın. Onay penceresindeki Pull from Git, commit edilmemiş kodun değiştirileceğini belirtir. Koruyacağınız çalışmayı önce commit edin veya Export ZIP / Download source ile dışarı alın.

Pull bir birleştirme veya çatışma çözme ekranı değildir. Yerel taslağınız ile başka bir yazarın değişikliğini birleştirmeniz gerekiyorsa dosyaları dışarı alın, Git aracınızda karşılaştırıp birleştirin ve doğru sürümü yeniden içe alın. Pull sonrasında Source farklarını tekrar inceleyin; yalnızca çalışma alanında bulunan dosyaların tamamının otomatik temizleneceğini varsaymayın.

Yeni bir proje dışarıdan depoya eklendiyse Projects → Pull projects from Git → Pull projects kullanın. Mevcut projenin dosyalarını yenilemek için o projedeki Pull işlemini seçin.

Bir dosyadaki değişikliği geri alma

1. Source → Files altında dosyanın değişiklik durumuna tıklayın.
2. Diff penceresindeki önceki ve mevcut içeriği karşılaştırın.
3. Dosyayı son kayıtlı Git sürümüne döndürmek için Undo changes seçin.

Bu işlem çalışma dosyasını geri alır; Git geçmişini yeniden yazmaz. Hiç commit edilmemiş dosyada geri dönülecek Git sürümü yoktur ve Undo changes kullanılamaz. Bir commit’i geçmişten kaldırma, dalı sıfırlama (reset), dallar arasında geçiş, pull request veya merge işlemleri Lunex arayüzünde sunulmaz; bunları Git hizmetinizde yönetin.

Kendi HTTPS Git deponuzu bağlama

Bu bölüm kurulum yöneticisi içindir. Proje başına depo seçmek yerine kurulumun ortak Git ayarını değiştirirsiniz. Aktif bir deponun adresini değiştirirken mevcut projelerin yeni depodaki dizinlerle nasıl eşleşeceğini önceden belirleyin.

1. Git hizmetinizde entegrasyonlar için ayrı bir depo ve kullanılacak dalı hazırlayın; örneğin integrations deposu ve main dalı. Ürün kaynak deposunu bu amaçla kullanmayın.
2. Lunex için ilgili depoyu okuyup hedef dala yazabilen bir teknik hesap veya erişim belirteci oluşturun. Korunan dal kurallarının bu çalışma biçimine izin verdiğini kontrol edin.
3. Kubernetes içindeki Lunex uygulamasının ve build podlarının Git adresini çözebildiğini ve TLS sertifikasına güvendiğini doğrulayın.
4. Kurulumun values.yaml dosyasında şu alanları doldurun:

git:
  enabled: false
  external:
    repository: https://git.example.com/integration-team/integrations.git
    username: lunex-automation
    password: "<git-access-token>"
    branch: main

password alanına sağlayıcınızın kabul ettiği parola veya erişim belirtecini girin. Örnekteki <git-access-token> yer tutucudur. Gerçek değeri sürüm kontrolüne almayın; kimlik bilgisi içeren values dosyasını erişimi sınırlı bir dosya olarak yönetin. Komut satırında --set ...password=... kullanmak yerine dosya kullanın.

5. Kurulum paketinin dizininden mevcut kurulum yönteminizi aynı values dosyasıyla çalıştırın:

chmod 600 /etc/lunex/customer-values.yaml
sudo ./install.sh --values /etc/lunex/customer-values.yaml \
  --ghcr-token-file /root/ghcr-token.txt

Çevrimdışı kurulumda imaj erişimi için kullandığınız --images <dizin> seçeneğini koruyun. Git erişim belirteci ile imajları indiren belirteç farklı amaçlara hizmet eder.

6. Lunex’te Projects → Pull projects from Git ile depoyu okuyabildiğinizi doğrulayın. Bir deneme projesinin küçük değişikliğini Commit and push ile gönderip Git hizmetinde görünmesini kontrol edin. Son olarak Build yaparak build podunun da aynı depoya eriştiğini doğrulayın.

Başarılı bağlantının iki koşulu vardır: uygulama pull/push yapabilmeli, build podu seçilmiş commit’i alabilmelidir. Yalnızca proje listesinin açılması ikincisini doğrulamaz.

Ayarların uygulama ve builder’a aktarılması

Chart, Git ayarlarını lunex adlı Kubernetes Secret içindeki şu anahtarlara yazar:

Chart uygulamanın depo ve dal değerlerini doğrudan ortam değişkeni olarak, kullanıcı/parolayı ise Secret referansı olarak verir. lunex Secret’ı yalnızca Lunex’in namespace’inde bulunur; build podunun Kubernetes erişimi yoktur, dört değeri her build başladığında Lunex bu Secret’tan okuyup build podunun bellek diskine yazar. Bu yüzden yalnızca uygulamanın ortam değişkenini değiştirip lunex Secret’ını eski bırakmayın.

credentials.existingSecret, genel kurulum kimlik bilgileri içindir; Git erişim bilgilerini bu Secret’a eklemek git.external ayarını otomatik değiştirmez. Mevcut chart’ta Git için ayrı bir existingSecret alanı bulunmaz. Harici Secret yönetimi kullanıyorsanız chart’ın ürettiği lunex Secret’ının sahipliğini kurulum yönteminize açıkça dahil edin; elle değiştirilen chart kaynakları sonraki yükseltmede yeniden yazılabilir.

Depo düzeni

integrations/
  order-intake/
    application.properties
    orders.camel.yaml
    deployment.jkube.yaml
  shipment-events/
    application.properties
    shipments.camel.yaml

Git deposunun kökünde proje dizinleri, bu dizinlerin altında kaynak dosyaları bulunur. Herhangi bir Maven monoreposunun iç içe dizinlerinin otomatik proje keşfiyle aynı biçimde alınacağını varsaymayın. Önce bir Lunex Export ZIP çıktısı veya Lunex’ten yapılmış ilk commit ile düzeni oluşturun.

SSH kullanan Git sunucusu

SSH erişimi kurulum düzeyinde anahtar dosyaları ve host doğrulaması gerektirir. Mevcut Helm chart’ı HTTPS alanlarını hazır olarak sunar; SSH anahtarını uygulamaya bağlayan volume ayarı için kurulum manifesti özelleştirilmelidir. Yalnızca depo adresini değiştirmek yeterli değildir.

Yönetici anahtarı ve doğrulanmış known_hosts dosyasını Secret üzerinden uygulamaya salt okunur bağlamalı, iki yol değişkenini vermeli ve aynı anahtarları lunex Secret’ına sağlamalıdır; Lunex bunları her build’e kendisi aktarır. Standart dışı portu Git URL’sinde belirtin, örneğin ssh://git@git.example.com:7999/team/integrations.git; uygulama ve builder aynı URL’yi kullanır. Host anahtarını Git sunucusu yöneticisinden doğrulayın. Bağlantı için host doğrulamasını kapatmayın.

Bu akışta tarayıcıdan anahtar yükleme veya anahtar parolası sorma adımı yoktur. Kurulumun anahtar biçimi ve erişim izinlerini hem uygulama pull/push hem builder checkout ile doğrulayın. SSH volume özelleştirmesini yükseltmelerde tekrar uygulanacak kurulum tanımında tutun.

Sorun giderme

Çalıştırma ve dağıtım ile düğmelerin etkilerini; geliştirmeden üretime sürüm örneği ile Git commit’inin imaja ve çalışan poda nasıl dönüştüğünü izleyebilirsiniz. Commit/push tek başına paketlenmiş runtime’ı güncellemez.