Claude Code ile repository’yi Testing Farm’a bağlayan skill

Red Hat, sclorg/ai-agents repository’sinde yayımlanan Testing Farm skill ile Claude Code’un bir repository’yi Testing Farm’a bağlamasını anlattı. Skill, TMT/FMF test metadata’sını ve GitHub Actions ya da GitLab CI pipeline tanımlarını üretiyor, Red Hat internal GitLab’ı da destekliyor.

Testing Farm nedir, ne işe yarar?

Testing Farm, Red Hat’in işlettiği ve testleri Fedora, CentOS Stream ve RHEL ortamlarında koşturan bir test servisidir. Testler TMT ile tanımlanır, servis API üzerinden tetiklenir ve sonuçları CI sistemine geri döner. Fedora ve RHEL ekosisteminde paket ve upstream proje testleri için kullanılır.

tmt nedir, ne işe yarar?

tmt (Test Management Tool), testleri ve test planlarını FMF adlı metadata biçimiyle tanımlamaya yarayan açık kaynak bir araçtır. Aynı tanımla testler yerelde, container’da ya da sanal makinede çalıştırılabilir. Fedora ve RHEL ekiplerinin test altyapısının temelinde yer alır.

Testing Farm skill ne işe yarıyor?

Testing Farm’a repository bağlamanın zor kısmı testin kendisi değil, etrafındaki iskelet. TMT plan ve test tanımları, .fmf dosyaları, CI workflow’u ve token yönetimi elle yazılınca ilk kurulum uzuyor. Testing Farm skill’i bu iskeleti Claude Code içinden çıkarıyor: repository’yi tarıyor, mevcut test suite’lerini buluyor, eksik bilgiyi soruyor ve .fmf dosyalarıyla workflow tanımını yazıyor.

Kaynaktaki örnek sclorg/ci-scripts. Bu repository’de TMT metadata yok, ama tox ile yazılmış testler var. Agent tox yapılandırmasından üç plan çıkarıyor: daily-tests, eol-checker ve ocp-stream-generator.

Kimin işine yarar?

• Fedora ya da RHEL üzerinde test koşturmak isteyen upstream projeler
• Red Hat internal GitLab’da tutulan bileşenler
• Testi tox, pytest ya da bash script olarak duran ama TMT’ye hiç geçmemiş repository’ler

Testleri zaten TMT ile tanımlı bir projede kazanç küçük. Orada agent’ın katkısı workflow dosyasıyla sınırlı kalır. O dosyayı elle yazmak da zor değil.

Kurulum: symlink mi, kopya mı?

Testing Farm skill’ini çalıştırmak için Claude Code CLI, api.testing-farm.io’dan alınmış bir token ve yerelde git ile tmt gerekiyor. Kaynağın önerdiği yol symlink:

git clone https://github.com/sclorg/ai-agents.git ~/ai-agents
cd /path/to/your/project
mkdir -p .claude/skills
ln -s ~/ai-agents/skills/testing-farm .claude/skills/testing-farm

Sonra claude oturumunda /testing-farm-onboarding komutunu verin. Tek satırlık kullanım da var: claude "Onboard this repo to Testing Farm".

Symlink pratik, ama bir bedeli var. ~/ai-agents dizininde yaptığınız her git pull skill’in talimatlarını değiştirir. Repository’ye dosya yazan bir agent için bu, okumadığınız bir değişikliğin bir sonraki çalıştırmada devreye girmesi demek. Ekip ortamında kopya yöntemi daha öngörülebilir: skill dosyası repository’de commit olarak durur, güncellemesi de pull request ile gelir.

Token ve trigger seçiminde dikkat edin

Agent eksik bilgiyi etkileşimli olarak soruyor ve Testing Farm API token’ını da bu adımda istiyor. Token’ı sohbete yapıştırırsanız model oturumunun context’ine girer. Daha temiz yol, token’ı GitHub ya da GitLab tarafında secret olarak kendiniz tanımlamak. Agent’tan da workflow’da token’ın kendisini değil, bu secret’a referansı kullanmasını isteyin.

İkinci konu trigger. Skill size pull request, main branch’ine push ve manuel dispatch seçeneklerini soruyor. GitHub, fork’tan gelen PR’larda pull_request olayıyla çalışan workflow’a secret geçirmez. Token gerektiği için workflow pull_request_target ile kurulursa durum değişir. Bu olayda workflow secret’lara erişir ve fork kodunu checkout edip çalıştırmak token sızıntısına yol açabilir. Üretilen workflow’daki on: bloğunu commit’ten önce satır satır okuyun.

Lint geçti, iş bitti mi?

Kaynak doğrulama için iki komut veriyor:

tmt plan lint
tmt test lint

Lint şema ve alan kontrolü yapıyor. Anahtarlar doğru mu, script tanımlı mı, test dizini var mı, bunlara bakıyor. Testin Testing Farm’da, seçtiğiniz compose üzerinde gerçekten geçip geçmediğini söylemiyor. Örnekteki T004 kontrolü test dizinini geliştiricinin yerel diskindeki yolla doğruluyor. Temiz bir Fedora makinesinde tox ve diğer bağımlılıklar kurulu mu, bunu ancak gerçek bir koşu gösterir.

Makul bir sıra şöyle:

1. Agent’ı ayrı bir branch’te çalıştırın.
2. git diff ile .fmf dosyalarını ve workflow’u okuyun.
3. İki lint komutunu çalıştırın.
4. Draft bir PR açıp ilk Testing Farm koşusunun sonucuna bakın.
5. Tek compose ile başlayın, örnekteki gibi Fedora-latest yeterli.

Matrix stratejisiyle birden fazla dağıtımı aynı anda test etmek mümkün. Ama ilk koşu yeşile dönmeden matrix’i açarsanız her hata dağıtım sayısı kadar çoğalır. Desteklenmeyen bir CI runner’ı ya da beklenmedik bir repository yapısı çıkarsa sclorg/ai-agents üzerinde issue açılabiliyor.