AIREITERFactory Automations; belirli bir zamanlamayla, üst düzey bir Slack mesajıyla, bir GitHub olayıyla veya gelen bir HTTP isteğiyle Droid oturumu başlatabiliyor. Webhook tetikleyicileri hâlâ Private Preview aşamasında. Zamanlamalar ise sabit UTC saatleriyle çalışıyor ve yaz saati uygulamasındaki değişiklikleri otomatik olarak takip etmiyor. Kapsamı sınırlandırılmış bir pilot için hazır; ancak üretimde kontrolsüz biçimde kullanılacak bir çözüm değil.
Factory Automations gerçekte ne çalıştırıyor?
Her otomasyon; bir tetikleyici, talimatlar, bir kimlik ve çalıştırma hedefinden oluşuyor (Factory belgeleri).
| Tetikleyici | Çalıştırmayı ne başlatır? | Temel çalışma ayrıntısı |
|---|---|---|
| Zamanlanmış | Doğal dille belirtilen sıklık veya beş alanlı cron ifadesi | Seçilen bilgisayarda ya da çalıştırma hedefinde çalışır; yönetilen bilgisayarlar 10 otomasyonu, bunların 5’ini ise bir dakikalık aralıkla zamanlamayı destekler |
| Slack | Eşleşen üst düzey kanal mesajı | Yanıtı, tetikleyicinin bulunduğu mesajın başlattığı konu dizisine gönderir |
| GitHub | Pull request’ler, yorumlar, push işlemleri, etiketler, kontroller veya zamanlama | Kurulum tamamlandıktan sonra GitHub Actions içinde çalışır |
| Webhook | Başka bir servisten gelen HTTP POST isteği | Droid Computer veya çalıştırma şablonu; Private Preview |
Bir otomasyon özel tutulabilir veya kuruluşla paylaşılabilir. Oturum gizliliği ise otomasyon çalıştırmalarıyla oluşturulan oturumları kimlerin açabileceğini ayrıca belirler.
Tetikleyici seçimi çalışma biçimini değiştiriyor
Zamanlanmış çalıştırmalar: başlamak için en güvenli seçenek
Zamanlamalar, “every Monday at 9am PST” gibi doğal dil ifadelerini veya 0 9 * * 1 gibi cron sözdizimini kabul ediyor. Factory, ortaya çıkan zamanı önizlemede gösteriyor; ancak cron ifadeleri UTC üzerinden çalışıyor. Yazıyla belirtilen saat dilimi sabit bir UTC zamanlamasına dönüştürülüyor ve yaz saati uygulamasına göre otomatik olarak güncellenmiyor (Factory belgeleri).
İlk denemeler için günlük durum özeti, bağımlılık denetimi, güncelliğini yitirmiş dokümantasyon kontrolü veya kodu birleştirmek yerine kanıtları hazırlayan bir PR inceleyicisi iyi seçenekler.
Slack mesajları: kullanışlı, ancak yalnızca üst düzey sinyaller için
Slack otomasyonu, erişilebilen bir kanalda eşleşen bir üst düzey mesaj yayınlandığında başlıyor. Konu dizisindeki yanıtlar tek başına yeni bir çalıştırma başlatmıyor. Filtrelerle kanal deseni, gönderen türü, anahtar kelimeler, hariç tutulacak kelimeler veya hariç tutulacak gönderenler sınırlandırılabiliyor.
Çalıştırmalar, tetikleyici mesajın konu dizisine yanıt veriyor. Birden fazla otomasyon eşleşirse yalnızca ilki aynı konu dizisine yanıt gönderiyor; diğerleri orijinal mesaja bağlantı veren ayrı mesajlar yayınlıyor. Factory, özel kanallara erişim kuralları da dahil olmak üzere bu davranışları belgelerinde açıklıyor (Factory belgeleri). Bu yapı kontrollü bir olay kanalı için uygun; ancak her takip mesajına bağlı iş akışları için değil.
GitHub olayları: görünür bir kurulum aşamasından sonra güçlü
Özel GitHub otomasyonları pull request’lere, push işlemlerine, yorumlara, etiket değişikliklerine, tamamlanan kontrollere veya bir zamanlamaya tepki verebiliyor. Çalıştırmalar GitHub Actions içinde gerçekleşiyor ve otomasyon oluşturulurken seçilen her depo için bir kurulum pull request’i açılıyor.
İş akışının etkinleşmesi için bu kurulum pull request’inin birleştirilmesi gerekiyor. İş akışı varsayılan dala ulaşmadan başlatılan çalıştırmalar başarısız oluyor. O zamana kadar otomasyon yorum gönderemiyor, commit push’layamıyor veya pull request açamıyor. Tekrarlanan işin zaten bir depo olayıyla tetiklendiği ve normal pull request incelemesinin dağıtım sınırı olarak korunacağı durumlarda en güçlü seçenek GitHub.
Webhook’lar: gerçek bir yetenek, ancak erişim sınırlı
Factory, webhook otomasyonlarını Private Preview olarak belgeliyor ve etkinleştirme için kuruluşların destek ekibiyle iletişime geçmesini istiyor. Webhook, harici bir HTTP POST isteğiyle çalıştırma başlatıyor; ancak kullanıcının yerel makinesinde çalışamıyor. Bunun için Droid Computer veya çalıştırma şablonu gerekiyor.
Factory bir webhook URL’si, X-Webhook-Secret başlık seçeneği ve başlık ayarlayamayan göndericiler için URL biçimi sunuyor. Belgelerde başlık kullanılması öneriliyor; çünkü URL içindeki gizli bilgiler günlüklerde görünebilir. Gizli anahtar yalnızca bir kez gösteriliyor ve anahtar döndürüldüğünde eski değer geçersiz hale geliyor (Factory webhook belgeleri).
Aynı belgelerde gövde boyutu için 200 KiB sınırı, dakikada 60 kabul edilen istek, 30 günlük teslimat kaydı, aynı gövde için 10 dakikalık tekilleştirme penceresi ve saatte 10 çalıştırma sınırı belirtiliyor. Bu kontroller webhook’ları uyarı yanıtı gibi senaryolarda test edilebilir kılıyor. Ancak erişimin öngörülebilir olması gereken üretim sistemleri için Private Preview durumu hâlâ engel.
Otomasyonu güvenli hale getiren kontroller
Zamanlanmış, Slack ve webhook otomasyonları kullanıcı olarak veya paylaşılan bir servis hesabıyla çalıştırılabiliyor. Kimlik seçimi bağlayıcı erişimini, faturalandırmayı ve Slack’teki gönderen bilgisini etkiliyor. Çalıştırma hedefi kuralları Factory belgelerinde listeleniyor.
İstemleri dar kapsamlı tutun, gerektiğinde iptal edilebilen kimlik bilgileri kullanın, özel bir çalıştırma hedefi seçin ve dağıtım ile birleştirme yetkisini mevcut depo kontrollerinde bırakın. Factory’nin Slack Marketplace listelemesi, uygulamanın hata yapabileceğini açıkça belirtiyor ve kullanıcıların kodu ve yanıtları mutlaka kontrol etmesini öneriyor.
Bir kullanıcı, Linux masaüstü uygulamasının ve bilgisayarlar arası senkronizasyonun bulunmaması gibi gözetim boşluklarına dikkat çekti (X’te @JoelDeTeves tarafından paylaşılan gönderi). Ekip, masaüstünden uzaktayken uzun süren otomatik çalışmaları denetlemeyi bekliyorsa bu eksikler önem kazanıyor.
Factory Automations mı, basit bir GitHub Action mı?
| İhtiyaç | Factory Automations | Basit GitHub Action |
|---|---|---|
| Bir istemi depo üzerinde çalıştırmak | Yerleşik Droid oturumu ve çalıştırma hedefi | Aracı çalışma zamanı ile iş akışı kodunu ekip sağlar |
| Zamanlanmış işler | UTC sınırlamasıyla doğal dil veya cron | GitHub cron’u ve özel mantık |
| Slack tetikleyicisi | Filtreler ve konu dizisi yanıtlarıyla üst düzey mesajlar | Slack uygulaması veya webhook altyapısı |
| GitHub olayı | Yönlendirmeli kurulum PR’ı ve GitHub Actions çalıştırması | Doğrudan iş akışı dosyası |
| Webhook | Yerleşik, ancak Private Preview aşamasında | Uç nokta, kimlik doğrulama, yeniden denemeler ve çalışan süreç oluşturmak gerekir |
| İnceleme sınırı | İşi insan incelemesine hazırlayabilir | İş akışının izinlerine bağlıdır |
İş, günlük PR özeti gibi deterministik API bağlantılarından ibaretse GitHub Action kullanın. Tekrarlanan adım araştırma, depo bağlamı, önerilen kod değişikliği veya insanın okuyabileceği bir oturum gerektiriyorsa Factory daha uygun. Kısa bir betik yazmaktan kaçınmak için yalnızca aracı bir platform seçmeyin.
Daha fazla yetki kazandırabilecek düşük riskli bir pilot
- Yeni pull request’leri incelemek veya oluşturulan dosyaları kontrol etmek gibi girdisi sınırlandırılmış, tekrarlanan tek bir görev seçin.
- Webhook yerine zamanlanmış bir otomasyonla başlayın. Böylece önizleme erişimi gerektirmez ve çalışma sıklığını incelemek kolaylaşır.
- Çıktıyı dağıtım veya birleştirme değil, rapor ya da pull request olarak belirleyin.
- Başarısız çalıştırmaları, engellenen işleri, değişen dosyaları ve insanların yaptığı düzeltmeleri kaydedin. Yalnızca kabul edilen pull request’ler yeterli kanıt değildir.
- Her seferinde yalnızca bir boyutu genişletin: başka bir görev sınıfı, depo veya tetikleyici.
Factory’nin iş akışı rehberi; ilk hatayı yeniden üretmeyi, düzeltmeyi temiz bir ortamda test etmeyi ve yeniden kullanılabilir bir talimatı kalıcı hale getirmeden önce benzer bir durumu kontrol etmeyi öneriyor. Bu yaklaşım, Automation pilotu için de mantıklı bir standart.
Sık sorulan sorular
Factory Automations webhook’ları destekliyor mu?
Evet; ancak webhook tetikleyicileri Private Preview aşamasında ve kuruluş düzeyinde etkinleştirme gerektirebilir. Çalıştırmalar için Droid Computer veya çalıştırma şablonu gerekiyor. Ayrıntılar için yukarıdaki webhook bölümüne bakabilirsiniz.
Slack konu dizisindeki yanıtlar otomasyonu tetikler mi?
Hayır. Çalıştırmayı yalnızca eşleşen bir üst düzey mesaj başlatır; ayrıntılar için Slack mesajları bölümüne bakın.
Zamanlama yaz saati uygulamasını takip eder mi?
Hayır. Factory sabit bir UTC zamanlaması kaydeder. Yerel yaz saati kuralları değiştiğinde zamanlamayı yeniden kontrol etmeniz gerekir. Ayrıntılar için Zamanlanmış çalıştırmalar bölümüne bakın.
GitHub otomasyonları kurulum pull request’i birleştirilmeden önce çalışır mı?
Hayır. Kurulum pull request’inin önce varsayılan dala ulaşması gerekir; bundan önceki çalıştırmalar başarısız olur. Ayrıntılar için GitHub olayları bölümüne bakın.
Bir webhook teslimatı tekrarlandığında ne olur?
10 dakika içinde alınan aynı gövde Deduped olarak kaydedilir ve yeni bir çalıştırma başlatmaz. Factory ayrıca filtrelenen, hız sınırına takılan, atlanan ve başarısız teslimatları da kaydeder.
Gözden kaçırılmaması gereken ödünleşim
Çıktı pull request inceleme döngüsü içinde kalabiliyorsa zamanlanmış veya GitHub tetiklemeli işleri pilot olarak deneyin. Slack, üst düzey mesaj kuralları net biçimde belirlendiğinde pratik bir seçenek. Webhook’lar test edilebilecek kadar ayrıntılı olsa da Private Preview statüsü, bunların henüz üretim amaçlı bir olay sisteminin temelini oluşturmasını engelliyor.