GitHub baru-baru ini memperkenalkan sokongan untuk YAML anchors dalam GitHub Actions , satu ciri yang membolehkan pembangun mentakrifkan blok konfigurasi yang boleh digunakan semula dalam fail aliran kerja mereka. Walaupun ini mungkin kelihatan seperti penambahbaikan yang mudah untuk mengurangkan pendua kod, penambahan ini telah mencetuskan perdebatan sengit dalam komuniti pembangun mengenai implikasi keselamatan dan keserasian alat.
Kontroversi ini berpusat pada sama ada ciri ini benar-benar meningkatkan aliran kerja atau mencipta lebih banyak masalah daripada yang diselesaikan. YAML anchors membolehkan pembangun mentakrifkan blok konfigurasi sekali dan merujuknya beberapa kali sepanjang fail aliran kerja mereka, yang berpotensi mengurangkan kod berulang. Walau bagaimanapun, pengkritik berpendapat pendekatan ini memperkenalkan kerumitan yang tidak perlu kepada platform yang sudah mencabar.
Alat Analisis Keselamatan Menghadapi Cabaran Baharu
Salah satu kebimbangan utama yang dibangkitkan oleh komuniti melibatkan kesan terhadap alat analisis keselamatan. Alat analisis statik yang mengimbas aliran kerja GitHub Actions untuk kelemahan kini menghadapi halangan teknikal yang ketara apabila memproses anchors . Isu ini berpunca daripada cara YAML parsers mengendalikan anchors - mereka biasanya meratakan kandungan anchored ke dalam setiap lokasi di mana ia dirujuk, menjadikannya hampir mustahil untuk menjejaki kembali ke lokasi sumber asal.
Ini mencipta masalah besar untuk alat keselamatan yang perlu menyediakan mesej ralat yang tepat dan laporan kelemahan. Apabila isu keselamatan dikesan dalam bahagian anchored , alat tersebut tidak dapat dengan mudah menunjukkan pengguna kepada definisi anchor asal, menjadikan penyahpepijatan dan pemulihan lebih sukar.
Alat dan Ekosistem yang Terjejas
- Analisis Keselamatan: zizmor , actionlint , claws , poutine
- Impak: Pemetaan lokasi sumber menjadi sukar
- Tingkah Laku Parser: Kebanyakan parser YAML meratakan anchor semasa deserialisasi
- Keserasian: Alat mesti dikemas kini untuk mengendalikan resolusi anchor
Penyelesaian Alternatif Sudah Wujud
Ramai pembangun dalam komuniti menunjukkan bahawa GitHub Actions sudah menyediakan beberapa mekanisme untuk mengurangkan pendua kod tanpa menggunakan YAML anchors . Pembolehubah persekitaran peringkat aliran kerja, aliran kerja yang boleh digunakan semula, dan konfigurasi peringkat kerja boleh menangani kebanyakan kebimbangan pendua sambil mengekalkan kejelasan dan keselamatan.
Perdebatan ini mendedahkan perselisihan asas mengenai falsafah reka bentuk aliran kerja. Ada yang berpendapat bahawa jika anda perlu berkongsi konfigurasi merentasi beberapa kerja, anda harus mempertimbangkan untuk membahagikan aliran kerja anda atau menyusun semula pendekatan anda sepenuhnya. Yang lain berpendapat bahawa anchors menyediakan fleksibiliti berharga untuk senario kompleks di mana penyelesaian sedia ada tidak mencukupi.
Pendekatan Alternatif yang Disebut
- Bahasa Konfigurasi: Dhall , CUE
- Penjanaan Kod: Skrip Python , Bash yang menjana YAML
- Ciri GitHub Sedia Ada: Blok env peringkat aliran kerja, aliran kerja boleh guna semula, konfigurasi peringkat kerja
- Ujian Tempatan: Alat seperti Earthly CI , act (dengan batasan)
Kebimbangan Pelaksanaan dan Ciri yang Hilang
Menambah bahan api kepada kontroversi ialah pelaksanaan tidak lengkap GitHub terhadap fungsi YAML anchor . Walaupun mereka menyokong anchors asas dan rujukan, mereka terutamanya mengecualikan merge keys - satu ciri yang akan membolehkan penggabungan beberapa konfigurasi anchored . Pengecualian ini mengelirukan ramai pembangun kerana merge keys mewakili salah satu daripada beberapa kes penggunaan di mana YAML anchors menyediakan nilai unik yang tidak boleh direplikasi melalui ciri GitHub Actions lain.
Komuniti juga telah membangkitkan kebimbangan mengenai pendekatan GitHub terhadap pematuhan YAML . Daripada menyokong sepenuhnya spesifikasi YAML , GitHub nampaknya melaksanakan subset tersuai, yang boleh membawa kepada kekeliruan dan isu keserasian pada masa hadapan.
Status Sokongan YAML Anchor
- Anchor Asas: Disokong oleh GitHub Actions
- Rujukan: Disokong oleh GitHub Actions
- Kunci Gabungan: Tidak disokong oleh GitHub Actions
- Versi YAML: Pelaksanaan tersuai GitHub (bukan pematuhan penuh 1.1 atau 1.2)
Kesan Alat Pembangun dan Ekosistem
Perubahan ini menjejaskan banyak alat popular dalam ekosistem GitHub Actions . Alat linting , pengimbas keselamatan, dan penganalisis aliran kerja kini mesti mengambil kira resolusi anchor apabila memproses fail aliran kerja. Ini mewakili cabaran kejuruteraan yang ketara untuk penyelenggara alat yang membina penyelesaian mereka berdasarkan andaian yang lebih mudah mengenai struktur aliran kerja.
YAML anchors seterusnya mengeruhkan abstraksi aliran kerja, kerja, dan langkah, dengan memperkenalkan bentuk keadaan global yang merentasi yang tidak bermain mengikut peraturan sistem yang lain.
Sesetengah pembangun mencadangkan bahawa daripada menambah lebih banyak ciri YAML , industri harus bergerak ke arah menggunakan bahasa pengaturcaraan sebenar untuk definisi saluran paip CI/CD . Alat seperti Dhall , CUE , atau bahkan menjana YAML daripada Python atau bahasa lain yang biasa boleh menyediakan keupayaan abstraksi yang lebih baik sambil mengekalkan kebolehujian tempatan.
Komuniti Berpecah Mengenai Faedah Praktikal
Walaupun terdapat kebimbangan teknikal, ramai pembangun mengalu-alukan YAML anchors untuk faedah praktikal segera mereka. Aliran kerja kompleks dengan blok konfigurasi berulang boleh menjadi lebih mudah diselenggara dengan anchors , terutamanya untuk senario yang melibatkan beberapa persekitaran penggunaan atau konfigurasi kerja yang serupa.
Ciri ini terbukti sangat berharga untuk penapis laluan dalam aliran kerja, di mana senarai laluan fail yang sama perlu dirujuk merentasi beberapa syarat pencetus. Sebelum ini, pembangun terpaksa sama ada mendua senarai ini atau menggunakan tindakan pihak ketiga untuk mencapai fungsi yang serupa.
Memandang ke Hadapan
Perdebatan ini menyerlahkan persoalan yang lebih luas mengenai hala tuju alat CI/CD dan pengurusan konfigurasi. Walaupun YAML anchors menyelesaikan titik kesakitan segera untuk sesetengah pengguna, ia juga mewakili langkah ke arah peningkatan kerumitan dalam ekosistem yang ramai sudah dapati mencabar untuk dinyahpepijat dan diselenggara.
Kontroversi ini menggariskan ketegangan antara menyediakan ciri berkuasa dan mengekalkan kesederhanaan dan keselamatan. Semasa GitHub Actions terus berkembang, komuniti berkemungkinan akan terus memperdebatkan sama ada ciri sedemikian meningkatkan atau merumitkan pengalaman aliran kerja pembangunan.
Rujukan: Dear GitHub: no YAML anchors, please