Pipeline dan automasi

Pipeline ialah separuh deterministik Control Center. Ejen menentukan apa yang hendak dikatakan; pipeline menentukan apa yang berlaku seterusnya, dengan cara yang sama setiap kali. Pipeline ialah DAG langkah yang boleh menghantar ejen, menjalankan skrip, mencabang berdasarkan syarat, menyebar merentas satu koleksi dan menyampaikan data antara langkah — dikekalkan, boleh disambung semula dan dikira kosnya.

Pipeline wujud atas tiga sebab: untuk merantaikan proses berulang yang berbilang langkah, untuk menyelaraskan beberapa ejen secara berurutan atau selari dan untuk bertindak balas terhadap sesuatu yang berlaku tanpa kehadiran manusia.

Templat dan larian

Satu templat (PipelineDefinition) ialah DAG deklaratif: langkah, input yang diisytiharkan dan konfigurasi. Ia tersimpan dalam pangkalan data ruang kerja itu sendiri. Satu larian (PipelineRun) ialah satu pelaksanaan templat itu, yang membawa wadah keadaan boleh ubah, jumlah kos dan token serta status setiap langkah.

Satu templat mempunyai banyak larian. Larian terselamat daripada mula semula: enjin memuat semula larian yang sedang berjalan dan menyambungnya semula dari tempat ia berhenti.

Dua jaring pengaman sengaja menggagalkan seluruh larian dan bukannya menyambung semula satu langkah, kerana menyambung semula akan lebih buruk daripada berhenti:

• Satu langkah yang telah suspended lebih lama daripada suspendedStepTimeout (lalai 24 jam) sedang menunggu tiket yang tidak akan pernah mencapai keadaan terminal, jadi langkah itu digagalkan untuk membebaskan larian. Pengecualiannya ialah extras['awaitApproval'] == true — itulah gerbang kelulusan separa orchestration.awaitApproval. human.gate tidak dikecualikan.
• Satu langkah yang diisytiharkan extras: {'idempotent': false} yang berada di pertengahan pelaksanaan apabila pelayan berhenti mungkin sudah menerapkan kesan sampingannya (squash merge, pembersihan worktree). Menjalankannya semula boleh menerapkannya dua kali, jadi enjin menggagalkannya dan menyerahkan percubaan semula kepada anda.

Jenis menjadualkan, badan bekerja

Satu langkah mempunyai dua bahagian yang ortogonal dan memisahkan kedua-duanya itulah yang membolehkan enjin kekal kecil.

Jenis (StepKind) memberitahu enjin bila sesuatu langkah menjadi boleh dijalankan berbanding langkah hulunya — itulah satu-satunya perkara yang perlu diketahui oleh penjadual. Terdapat enam: trigger, listen, join, router, forEach dan terminal. Badan (bodyKey) ialah kerja yang dilakukan oleh langkah itu setelah dijadualkan. Badan ialah closure yang didaftarkan mengikut kunci semasa permulaan pelayan, jadi banyak langkah daripada jenis yang berbeza boleh berkongsi satu badan: contohnya beberapa langkah listen yang semuanya menjalankan conversation.promptAgent.

Oleh sebab semantik penjadualan terletak dalam enam jenis, katalog tingkah laku boleh berkembang tanpa sesiapa menyentuh penjadual. Lihat Jenis langkah pipeline untuk katalog lengkap jenis, badan dan konfigurasinya.

Dua akibat daripada reka bentuk registri ini wajar diketahui sebelum anda mengarang templat secara manual:

• Satu langkah yang bodyKey-nya tidak didaftarkan menghasilkan amaran semasa templat dimuatkan dan selepas itu tidak pernah dilaksanakan. Tiada apa-apa yang gagal secara lantang semasa masa jalan. Langkah trigger dan terminal dikecualikan daripada amaran itu: pencetus masih menjalankan badan pipeline.trigger yang tidak melakukan apa-apa supaya pendengar hiliran terpicu; langkah terminal tiada badan dan merupakan sentinel penjadual.
• Kunci dalam peta extras sesuatu nod mesti sepadan tepat dan jika tidak akan diabaikan secara senyap. Hanya extras['spaceId'] meletakkan kerja langkah ejen dalam perbualan yang sedia ada. extras['mode'] (chat / plan / review) dibaca pada nod yang membuka ruang itu (messaging.createSpace, lalai review) — langkah ejen yang datang kemudian tidak boleh menetapkan semula kebenaran perbualan yang telah disertainya. Apa-apa ejaan lain bagi mana-mana kunci itu akan diabaikan.

Keadaan dan aliran data

Langkah tidak memanggil satu sama lain. Ia membaca daripada dan menulis ke wadah keadaan yang dikongsi pada larian: satu langkah membaca inputnya mengikut kunci, melaksanakan tugasnya dan menulis semula outputnya di bawah outputKey miliknya sendiri. StateReducer menggabungkan tulisan serentak apabila cabang selari mensasarkan kunci yang sama dan TemplateRenderer menggantikan pemegang tempat {{...}} dalam prompt dan skrip daripada keadaan yang sama itu.

Inilah sebabnya pipeline boleh diperiksa selepas kejadian — wadah keadaan itulah keseluruhan kisah larian tersebut.

Apa yang memulakan satu larian

Baris PipelineTrigger mengisytiharkan bila sesuatu templat bermula secara automatik. Terdapat empat jenis:

Pencetus	Memulakan satu larian apabila
Acara domain	Acara domain yang sepadan terpicu — contohnya PullRequestPublished atau TicketAssigned
Jadual	Ungkapan cron/interval sampai tempohnya
Manual	Anda menjalankannya secara manual; kehadiran pencetus manual yang didayakan itulah yang meletakkan templat dalam pemilih larian
Webhook	Sistem luar menghantar POST ke /webhooks/<token> pada port HTTP pelayan

Pencetus peristiwa ialah himpunan tertutup: 16 jenis peristiwa dikenali oleh penghantar dan ditawarkan dalam pemilih (EventPayloadMapper.knownEventTypes) dan tiada apa-apa lagi yang boleh memulakan pipeline. Empat belas daripada 16 jenis itu mempunyai pemetaan muatan. Dua — TicketCreated dan TicketStatusChanged — tidak mempunyainya, jadi pencetus pada mana-mana satu daripadanya kekal didayakan dan tidak pernah terpicu. Lihat Acara domain untuk senarai penuh.

Token webhook berfungsi sekali gus sebagai rahsia HMAC: pengepala X-Hub-Signature-256: sha256=<hex> permintaan itu disahkan terhadap HMAC-SHA256(body, token), penghantaran yang tidak disahkan ditolak dan tidak boleh dimainkan semula dan pendua digugurkan oleh dedupe_key. Oleh sebab baris pencetus unik pada (ruang kerja, jenis peristiwa, templat), sesuatu templat boleh menyimpan paling banyak satu pencetus webhook dan satu pencetus bagi setiap jenis acara domain.

Templat terbina dalam menyemai pencetus manual dan peristiwa mereka dalam keadaan didayakan; pencetus berjadual disemai dalam keadaan dilumpuhkan, jadi sapuan berulang sentiasa perlu diaktifkan sendiri.

Templat yang disertakan dalam keadaan dilumpuhkan

Tiga belas templat pipeline disemai ke dalam setiap ruang kerja dan lapan daripadanya disertakan dalam keadaan dilumpuhkan: external_pr_welcome, cross_review, ticket_to_pr, pr_triage, pre_merge_gate, release_notes, dep_audit dan pr_digest.

Inilah bahagian yang mengejutkan orang. Pencetusnya disemai dalam keadaan didayakan, tetapi PipelineEngine.start menolak templat yang dilumpuhkan dan memulangkan null — jadi pencetus itu terpicu ke dalam kekosongan dan tiada larian muncul. Templat, bukan pencetus, ialah suisnya. Dayakan ia di Tetapan → Ruang kerja → Templat pipeline sebelum mengharapkan mana-mana daripada lapan templat itu melakukan apa-apa.

Penyemaian semula sesuatu ruang kerja mengekalkan apa sahaja yang anda pilih: tetapan isEnabled anda dan baris pencetus sedia ada anda kekal. Terdapat tepat satu pengecualian yang disengajakan — jadual harian pr_merged_cleanup dipaksa didayakan walaupun ia dimatikan sebelum ini, kerana ia ialah pengumpulan sampah. Tanpanya, baris worktree, partition graf kod dan salinan salin-semasa-tulis akan terkumpul dan itu tidak pernah dimaksudkan sebagai pilihan pengguna.

Satu lagi asimetri yang wajar diketahui: templat terbina dalam pr_review sengaja tidak lagi menghantar ke GitHub. Menerbitkan semakan ialah langkah berasingan yang digerbangi pengguna dan pipeline yang menghantar secara terus akan menerbitkan dua kali. cross_review, ticket_to_pr dan pr_triage masih menghantar komen terus ke GitHub apabila dijalankan.

Apa yang diketahui oleh enjin

PipelineEngine mencipta rekod larian, menjadualkan nod permulaan yang sepadan dengan jenis peristiwa larian itu, dan kemudian menelusuri DAG: apabila langkah selesai, ia menilai pencetus hiliran, menyelesaikan cabang router, menunggu pada join, menggunakan polisi cuba semula dan tingkah laku terus walaupun gagal, serta menyimpan keadaan, kos dan ralat pada setiap langkah. Tepi yang meninggalkan nod permulaan yang lain diabaikan bagi larian itu, jadi pencetus jadual tidak menunggu syarat yang khusus untuk pencetus manual.

Apa yang tidak diketahuinya ialah apa-apa tentang penetikan, penghantaran, GitHub atau pemesejan. Satu-satunya titik sambungan lanjutannya ialah PipelineBodyRegistry. Badan yang didaftarkan di situ itulah yang memegang AgentDispatchPort, MessagingPort dan port seumpamanya — itulah sebabnya menambah keupayaan pada pipeline tidak pernah bermakna mengubah penjadual.

Pengendalian ralat

Langkah yang gagal merekodkan mesej ralatnya dan beralih ke failed. Jika langkah itu mengisytiharkan continueOnFail, langkah hiliran diteruskan dan ralat itu disimpan dalam keadaan larian; jika tidak, larian gagal. Langkah yang mempunyai StepRetryPolicy dicuba semula terlebih dahulu, dengan backoff linear atau eksponen, sebelum mana-mana daripada kedua-duanya terpakai.

Lihat juga

• Acara domain: perkara yang didengari oleh pencetus peristiwa
• Orkestrasi: pelan yang anda luluskan, yang dikompilasi menjadi salah satu pipeline ini
• Tiket dan perwakilan: perkara yang dicipta dan diselesaikan oleh langkah pipeline
• Jenis langkah pipeline: katalog lengkap jenis, badan dan konfigurasi
• Bina pipeline pertama anda
• Cipta templat pipeline
• Jalankan pipeline secara manual
• Pantau larian pipeline
• Sediakan pencetus pipeline