GitHub Actions Bisa Jauh Lebih Baik

 (blog.yossarian.net)
2 poin oleh GN⁺ 2023-09-24 | 1 komentar | Bagikan ke WhatsApp
  • GitHub Actions berguna dari sisi produktivitas dan fitur, tetapi dalam penulisan workflow nyata, debugging yang lambat, kesalahan keamanan, ketiadaan tipe, dan kurangnya action resmi berulang kali menyebabkan hilangnya waktu
  • Bahkan untuk perubahan kecil, kita harus berulang kali menjalankan git add; git commit; git push dan memeriksa log di browser, dan ada kasus di mana bahkan workflow rilis sederhana membutuhkan 4 commit dan rilis yang gagal
  • Ekspansi ${{... }}, pull_request_target, izin default GITHUB_TOKEN yang terlalu luas, dan referensi SHA dari fork semuanya merupakan titik keamanan yang mudah menimbulkan kesalahan, terutama SHA fork yang bisa tampak seperti commit dari repositori yang dimaksud
  • Input action tidak memiliki validasi type:, dan cakupan dukungan juga berbeda antara workflow_call dan workflow_dispatch, sehingga alih-alih input array atau objek, kita harus menangani sendiri string gaya CSV atau input yang diratakan
  • Validasi saat push, pemeriksaan keamanan saat runtime, pengurangan izin token default di repositori pribadi, pemeriksaan tipe yang lebih ketat, dan lebih banyak action resmi maupun semi-resmi dapat meningkatkan keandalan workflow

GitHub Actions berguna, tetapi berulang kali menghambat pekerjaan

  • GitHub Actions adalah alat yang sejak 2019 sangat membantu produktivitas dan rasa aman hingga digunakan setiap hari baik di proyek profesional maupun proyek hobi
  • Perluasan fiturnya juga terus berlanjut
  • Meski begitu, dalam proses pengembangan nyata alat ini juga bisa menjadi penyebab frustrasi besar dan hilangnya waktu

Debugging terlalu berat bahkan untuk kesalahan kecil

  • Ada kasus di mana saat menyiapkan workflow rilis, dibutuhkan 4 commit dan 4 rilis yang gagal hanya untuk menangkap kesalahan kecil
    • Tidak menggunakan ${{ ... }} di tempat yang diperlukan
    • Lupa menambahkan relasi needs:
  • Siklus debugging saat ini memiliki terlalu banyak langkah bahkan hanya untuk memeriksa satu kesalahan sederhana
    • Harus berpindah ke browser dari lingkungan pengembangan
    • Harus mencari tab yang benar
    • Harus masuk dengan mengklik ringkasan Actions dan layar status
    • Harus me-refresh log konsol yang dibuffer sambil mencari kesalahan berikutnya
  • Bahkan perubahan kecil bisa memakan waktu lebih dari 30 detik untuk seluruh proses

  • Arah perbaikan

    • Harus menyediakan shell debugging interaktif, atau setidaknya memungkinkan workflow dijalankan ulang dengan perubahan kecil tanpa git add; git commit; git push
    • Pengaturan repositori harus bisa menolak workflow yang jelas salah pada saat push
      • Sintaks yang tidak mungkin berjalan
      • Referensi ke job atau step yang tidak ada
      • Situasi di mana workflow diam-diam tidak berjalan karena YAML yang salah

Kesalahan keamanan terlalu mudah terjadi

  • Di GitHub Actions, workflow yang ditulis pengguna mudah sekali menjadi rentan tanpa disengaja
  • Saat ekspansi ${{ ... }} digunakan di shell atau konteks eksekusi lain, jika nilai ekspansi adalah input yang dikendalikan pengguna, hal itu bisa berujung pada injeksi kode berbahaya
    • Dalam contoh, kode disuntikkan melalui inputs.frob dan $MY_IMPORTANT_SECRET bisa bocor
  • pull_request_target sangat sulit digunakan dengan aman dalam workflow yang tidak sepele
    • Kasus penggunaan yang dimaksud tampaknya sempit, seperti memberi label atau menambahkan komentar pada PR dari fork
    • Tetapi dalam praktiknya fitur ini terekspos seperti foot-gun besar
  • Izin pada level workflow dan job juga mudah diatur terlalu longgar
    • Hak akses default GITHUB_TOKEN biasa sangat luas
    • Di repositori akun pribadi, pengurangan izin token default sering terlupakan
    • Karena tidak mengetahui persis cakupan izin yang dibutuhkan, orang cenderung memberi izin token secara berlebihan
  • Model izin GitHub menambah kebingungan karena dipaksakan ke satu sumbu read/write/none
    • id-token: write memungkinkan pembacaan token OpenID Connect milik workflow
    • Beberapa operasi GET untuk security advisory memerlukan izin write, sementara operasi lain hanya memerlukan read

Action yang dipatok dengan SHA bisa membingungkan dengan commit fork

  • Referensi seperti actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e belum tentu sebenarnya commit dari repositori actions/checkout
  • SHA tersebut adalah commit yang ada di fork dalam jaringan actions/checkout, dan karena penggunaan alternates oleh GitHub, commit itu bisa tampak seolah milik repositori induk
  • Tulisan terkait dari Chainguard membagi masalah ini menjadi tiga bagian
    • Referensi SHA fork dan referensi SHA repositori target tidak dibedakan secara visual
    • /repos/{user}/{repo}/commits/{ref} pada GitHub REST API mengembalikan respons JSON yang tampak hanya merujuk ke {user}/{repo} meski {ref} hanya ada di fork
    • Jika SHA fork dan non-fork tidak bisa dibedakan, pembatasan sumber tepercaya di GitHub Actions dapat dilewati
  • Respons GitHub sejauh ini hanya sebatas menambahkan kalimat tambahan di dokumentasi

  • Arah perbaikan

    • Diperlukan mode paranoid workflow security yang menolak workflow yang jelas tidak aman pada saat push
    • Seperti instrumentasi runtime semacam AddressSanitizer, pola yang berisiko secara keamanan selama eksekusi workflow harus bisa menyebabkan kegagalan
      • Contoh: gagal jika actions/checkout digunakan dengan ref selain repositori target di pull_request_target
    • Menghentikan atau menghapus pull_request_target juga bisa dipertimbangkan
    • Bahkan di repositori pribadi, cakupan default GITHUB_TOKEN harus bisa diatur lebih ketat seperti pada organisasi atau enterprise
    • Action yang dipatok ke SHA yang tidak ada di repositori yang dirujuk dan hanya ada di fork seharusnya ditolak secara default

Sistem tipe kurang konsisten dan kurang ekspresif

  • Custom GitHub Action dapat mendefinisikan input di bawah inputs:, tetapi input action tidak memiliki pemaksaan tipe
  • Deklarasi seperti type: number tidak berfungsi pada input action
  • Bahkan di dalam GitHub Actions sendiri, lokasi dukungan tipe tidak konsisten
    • workflow_call: mendukung boolean, number, string
    • workflow_dispatch: mendukung boolean, choice, number, string
    • input action: tidak ada dukungan tipe
  • Bahkan input yang mendukung tipe pun tidak mendukung struktur data kompleks seperti array atau objek
    • Tidak bisa menggunakan input array seperti paths: [foo, bar, baz]
    • Tidak bisa menggunakan input objek dengan hierarki di bawah headers:
  • Akibatnya penulis action harus meminta format input sementara
    • Mengimplementasikan sendiri parsing gaya CSV seperti paths: foo,bar,baz
    • Meratakan struktur yang alami menjadi seperti header-foo, header-baz
  • Pendekatan ini tidak baik untuk pemeliharaan maupun keamanan
    • Harus mengelola sendiri satu namespace input datar
    • Untuk input yang kompleks, akhirnya tercipta bahasa ad hoc yang tidak terspesifikasi

  • Arah perbaikan

    • Penulis action dan workflow harus bisa menggunakan type: di semua tempat
    • choice juga harus bisa digunakan di semua tempat, bukan hanya dibatasi pada workflow_dispatch
    • Jika tipe bisa diinferensi secara statis, perubahan workflow dengan tipe yang salah harus ditolak pada saat push
    • Diperlukan type: object dan type: array
    • Meskipun tidak akan sempurna karena tipe internal bisa heterogen, ini tetap akan lebih baik daripada kondisi sekarang
    • Jika perlu, data dapat diteruskan sebagai string serialisasi JSON
    • GitHub Actions sudah memiliki fungsi fromJSON(...)

Action resmi berhubungan langsung dengan kepercayaan pada platform

  • Ekosistem pihak ketiga GitHub Actions memiliki banyak action berkualitas tinggi
  • Di bawahnya ada action resmi yang dipelihara GitHub
    • Pekerjaan inti git: actions/checkout
    • Pekerjaan GitHub dan pengelolaan repositori: actions/{upload,download}-artifact, actions/cache, actions/stale
    • Pengaturan penting: actions/setup-python, actions/setup-node
  • Karena action ini bersifat umum dan penting, implementasi resmi yang dipelihara memiliki nilai besar
  • Namun jumlah action resmi sedikit, dan bahkan pekerjaan yang langsung menghubungkan fitur GitHub kadang tidak disediakan sebagai action resmi
    • Contoh: action untuk menambahkan pull request ke merge queue secara terprogram
    • GitHub CLI memiliki gh pr merge, tetapi tidak diekspos sebagai action

  • Contoh action resmi yang dihentikan

  • Arah perbaikan ekosistem

    • Tugas yang langsung menghubungkan berbagai bagian infrastruktur GitHub, dan pekerjaan yang saat ini harus ditangani manual lewat panggilan REST API atau menjalankan gh, layak disediakan sebagai action resmi
    • Dengan bekerja sama dengan action pihak ketiga besar, bisa dibentuk organisasi semi-resmi seperti community-actions
      • Action yang telah ditinjau oleh GitHub
      • Mematuhi praktik terbaik keamanan repositori
      • Pembaruan versi semantik
      • Jalur kepercayaan yang jelas untuk action penting dalam ekosistem

Alat yang ada dan roadmap GitHub

  • Banyak orang merekomendasikan alat emulasi GitHub Actions lokal nektos/act
    • Berguna untuk mengulang dan men-debug workflow sederhana dengan cepat
    • Tetapi karena image dan event-nya kadang tidak sepenuhnya sama dengan lingkungan GitHub yang sebenarnya, alat ini dinilai memiliki keterbatasan
  • rhysd/actionlint digunakan untuk linting lokal dan linting keamanan
    • Keterbatasannya adalah hanya bisa me-lint workflow dan tidak bisa me-lint action
  • GitHub Actions extension for VS Code menyediakan lint di editor dan integrasi workflow repositori
    • Berdasarkan JSON schema publik
    • Menyediakan tampilan workflow yang sedang berjalan, pelengkapan variabel, dan lain-lain
    • Tetapi masih tidak bisa mendeteksi masalah seperti salah ketik pada secrets atau salah ketik pada nama output yang dibuat secara dinamis, sehingga debugging add-commit-push tetap diperlukan
  • Julian Dunn, penanggung jawab manajemen proyek GitHub Actions, membagikan beberapa fitur yang sedang berjalan dan prioritasnya
    • Debugging interaktif ada di roadmap publik GitHub Actions
    • Upaya untuk berpindah dari workflow pinning berbasis tag·SHA ke pendekatan yang lebih immutable juga ada di roadmap publik
    • GitHub memprioritaskan kesehatan dan kualitas ekosistem action resmi, dan mengambil strategi menjaga jumlah action resmi tetap kecil agar tiap action bisa mendapatkan pemeliharaan dan perhatian yang memadai

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-24
Pendapat di Hacker News

  • Ada dua pendekatan untuk workflow GitHub Actions. 1) “Memprogram” dengan GitHub Actions, bahkan untuk hal seperti mengirim email pun memasang tool dari marketplace, YAML membengkak menjadi 500–1000 baris, penuh percabangan kondisi, dan sulit dipahami
    2) GitHub Actions hanya dipakai untuk “konfigurasi”, sambil terus bertanya, “Bisakah kompleksitas YAML ini dipindahkan ke skrip?” Jika pengiriman email juga dimasukkan ke skrip, workflow selesai dalam sekitar 50–60 baris, dan karena skrip bisa di-debug secara lokal, siklus bodoh push-debug-commit hampir hilang. Setiap kali masuk ke tim baru, saya selalu bilang bahwa 1 adalah jalan menuju kegilaan dan 2 lebih masuk akal, tetapi kira-kira separuh orang tetap memilih 1. Kurangnya alat debugging dan vendor lock-in juga jauh berkurang jika memilih 2

    • Saya sangat setuju dengan sudut pandang ini. Jika GitHub Actions tidak dicoba diprogram dengan YAML dan hanya diperlakukan sebagai berbasis eksekusi tugas, banyak rasa sakit akan hilang
      Namun sering kali tidak cukup hanya dengan memindahkan semuanya ke bahasa pemrograman yang layak. Ada kalanya harus memakai fitur khusus vendor dari GHA, menandai dependensi antar-task, atau memanggil REST API yang sudah diabstraksikan dengan baik sebagai action. Itu bisa diimplementasikan ulang dalam bahasa pilihan, tetapi vendor dependency tidak ikut hilang dan tetap rapuh. Pada akhirnya, proposisi nilai vendor lock-in GHA sangat kuat, sehingga untuk meyakinkan orang memilih nomor 2 diperlukan keunggulan yang lebih kuat
    • Pendekatan nomor 2 juga memudahkan developer menjalankan build secara lokal. Debugging lokal serta lingkungan testing/staging/production memakai build chain yang sama, dan tidak perlu mempertahankan prosedur build yang berbeda-beda
      Ini berlaku bukan hanya untuk GHA, tetapi untuk semua build server. Build server seharusnya menjadi executor skrip yang menambahkan histori, pengelolaan artifact, permission/audit, sementara proses build sebenarnya didelegasikan ke repository target build
    • Sudut pandang yang bagus. Namun jika ingin mengotomatisasi GitHub itu sendiri, misalnya untuk tugas seperti assignment role atau pemberian tag, pendekatan nomor 1 sulit dihindari. Meski begitu, saat ini saya lebih ingin menangani sebagian besar hal secara manual daripada mengalami debug loop GHA yang mengerikan
      Sebagai referensi, ada nektos/act yang mencoba mereproduksi perilaku GHA secara lokal: https://github.com/nektos/act
    • Saya penasaran bagaimana cara men-debug action. Menghabiskan waktu terlalu lama dalam loop commit-action-debug-change itu sampai terasa tidak masuk akal. Saya sepenuhnya setuju bahwa pendekatan nomor 2 membuat debugging skrip jauh lebih mudah. CI harus bisa dijalankan secara lokal, tetapi GitHub Actions, meskipun ada beberapa tool, tidak mudah dipakai seperti itu
    • Alasan utama mengarah ke nomor 2 adalah agar build tetap bisa dijalankan secara lokal ketika GitHub down, dan jika perlu mudah dipindahkan ke tempat lain
      Build/test/sign/deploy dan sebagainya sebaiknya ditulis sebagai skrip seportabel mungkin, dan skrip ini harus selalu berjalan secara lokal. GitHub hanya dianggap sebagai pihak yang otomatis menyiapkan lingkungan untuk menjalankan skrip itu dan benar-benar mengeksekusinya

  • Loop git commit, push, wait adalah pengalaman pengguna yang buruk. Pengguna berhak mendapatkan pipeline portabel yang berjalan di mana saja, termasuk mesin lokal. Act sampai batas tertentu menyelesaikan masalah ini, tetapi umumnya tidak benar-benar merepresentasikan environment asli
    Memang banyak pipeline yang tidak bisa dijalankan secara lokal seperti production, tetapi pada tahap development yang kurang kritis, tidak ada alasan workflow seperti ini tidak bisa ditangkap dan dijalankan secara lokal. Garden menyediakan pipeline portabel dan menambahkan caching di seluruh dependency graph. Beberapa pelanggan memangkas waktu eksekusi lebih dari 80%, dan developer bisa langsung melihat test lulus/gagal tanpa harus push ke git terlebih dahulu. Ini open source: https://github.com/nektos/act, https://docs.garden.io

    • Jika alih-alih menjejalkan skrip bash ke dalam action, orang hanya membuat action memanggil make atau skrip bash, masalah seperti ini tidak akan ada. CI/CD dan developer sama-sama harus memakai target/perintah yang sama seperti make release
    • Sepertinya prinsip “CI tidak boleh spesial seperti kepingan salju” banyak hilang ketika kita mulai membentuk tim khusus DevOps dan tool DevOps. Begitu sesuatu menjadi profesi, rasanya kita mencapai titik balik ketika hal itu menjadi terlalu rumit. Saya melihat fenomena yang sama pada Agile dengan huruf besar dan scrum master yang harus mengisi waktu
    • Karena ketidaksempurnaan Act, saya beberapa kali pernah menyelidiki arah yang salah. Untuk sekarang saya kembali dulu ke loop lama, dan berharap seiring waktu akan membaik
    • Build pipeline juga membutuhkan sesuatu seperti Terraform. Jika Anda memakai Bitbucket, semoga Tuhan menolong
    • Landing page garden.io terlihat rusak di iOS. Tampilannya meluap ke sisi kanan layar

  • Saya sepenuhnya memahami penderitaan saat men-debug eksekusi GH Actions. Alat yang tersedia praktis hanya menyalakan debug lalu menjalankannya ulang. Ada terlalu banyak commit sampah yang dibuat untuk memperbaiki atau men-debug pipeline, dan kebanyakan hanya sekadar melempar sesuatu untuk melihat apakah berhasil
    Bahkan hal yang sangat mendasar seperti logika yang bisa dipakai ulang pun dibuat tidak perlu rumit atau dokumentasinya buruk. Setelah tahu caranya, sebenarnya cukup mudah, tetapi dokumentasi GitHub buruk sekali. Kelihatannya untuk mendapatkan reusability kita harus membuat action publik atau menaruhnya di repositori lain, tetapi sebenarnya kita bisa membuat file YAML baru yang berisi logika reusable. Hanya saja, file itu harus berada di root folder workflows agar berfungsi. GH Actions benar-benar menyakitkan untuk dikerjakan, tetapi begitu berjalan, sangat nyaman. Akan bagus jika ada semacam local runner untuk menguji action sebelum commit dan push

    • Ada cara memakai draft PR untuk kasus seperti ini. Di draft PR, perubahan YAML action bisa dijalankan, dan setelah puas, commit bisa di-squash seperlunya di PR untuk merge sungguhan sehingga masuk tanpa berantakan. Saat men-debug atau mengembangkan logika GH Action, draft PR cukup bagus
    • Tidak bisa melakukan semuanya, tetapi ada alat yang cukup berguna: https://github.com/nektos/act
    • Saat memperbaiki CI, saya selalu mengunggahnya ke feature branch dan melakukan squash merge setelah selesai. Perbaikan cepat yang selesai sekali jalan hampir tidak pernah ada; biasanya selalu menjadi 3–10 commit
    • Saya pernah mencoba menjalankan image GitHub runner, atau image tiruannya, tetapi konfigurasi dan perilaku beberapa fiturnya terlalu menyakitkan. Setelah dua hari saya menyerah
      Ini juga bukan hanya masalah GitHub. Platform CI besar lainnya juga tidak jauh lebih baik dalam hal workflow dan integrasi. Sekarang saya sebisa mungkin membuat semuanya menjadi skrip
    • Inilah alasan utama kami membuat Earthly. Untuk menjalankan build secara lokal dan mendapatkan konsistensi dengan CI

  • GitHub Actions adalah sistem CI/CD yang buruk. Ia tidak bisa menjalankan langkah secara paralel di VM yang sama, dan pekerjaan berbasis container diperlakukan seperti warga kelas dua
    Karena masalah pertama, kita tidak bisa memparalelkan penyiapan kredensial lokal atau dependensi lingkungan. Melihat google-github-actions/setup-gcloud memakan waktu lebih dari 1 menit itu membuat kesal. Karena masalah kedua, sangat sulit membuat konfigurasi yang mengekspresikan setup lingkungan CI lewat Dockerfile di dalam repositori, membangun ulang image CI ketika isi image berubah lalu membuat workflow yang bergantung pada image tersebut menunggu, dan jika isinya tidak berubah, langsung menjalankannya dengan dependensi yang sudah terpasang tanpa membangun ulang. Di GitHub Actions, kita jadi selalu berusaha mengisi cache lagi setiap kali. Cache dibatasi 5GB, tidak bisa dinaikkan meski membayar, dan akan terdorong keluar secara FIFO, sehingga begitu melewati 5GB pada praktiknya sama saja seperti tidak ada cache. Saya benar-benar merindukan Concourse. Dulu hal-hal seperti pekerjaan paralel, pemicu pipeline kustom, masuk ke lingkungan CI lewat SSH untuk debugging, menjalankan pekerjaan sekali jalan tanpa pipeline, dan meneruskan isi direktori antar-pekerjaan tanpa membuat artefak semuanya memungkinkan. GitHub Actions lebih mirip CI/CD mainan yang populer karena ambang masuknya mudah—cukup taruh satu file di .github/workflows dan langsung bisa dipakai. Bagus untuk mengajak orang mulai memakai, tetapi begitu melewati fungsi awal, ia tidak cukup kuat untuk disebut “terbaik”

    • Karena batas cache 5GB, sekarang saya mungkin bisa menyelidiki masalah “build caching yang anehnya rusak”. Terima kasih sudah memberi tahu
    • Concourse luar biasa. Saya tidak tahu timnya sudah dibubarkan, sayang sekali. Cara komunikasi Zito juga terbaik
    • Menurut saya itu lebih dekat ke VMWare yang membubarkannya setelah akuisisi, bukan Pivotal. Di internal ada banyak orang yang menyukai Concourse. Namun saya sudah pergi sebelum akuisisi
      Debugging SSH dan pekerjaan sekali jalan benar-benar terasa seperti mimpi
    • Penasaran apakah Anda sudah melihat Tekton: https://tekton.dev/
    • Ada solusi yang sudah ada yang mempertimbangkan cukup banyak dari masalah-masalah ini. Saya ingin mendengar pendapat Anda. Akan bagus jika Anda membagikan email atau menghubungi lawnchair@lawnchair.net

  • Saya tidak mengerti bagaimana masalah bahwa GitHub tidak bisa membedakan referensi SHA dari fork dan non-fork, sehingga fork dapat melewati pengaturan keamanan GitHub Actions, masih belum diselesaikan
    Jika kontrol keamanan bisa dengan mudah dilewati, itu adalah isu keamanan serius. Memang harus meyakinkan seseorang untuk memakai SHA saya, tetapi rekayasa sosial biasanya termasuk mudah

  • Jujur saja, ini sampai memalukan betapa buruknya. Aneh juga bahwa kegagalan build yang tidak terkait secara kebetulan hanya mengirim notifikasi ke maintainer terbaru yang terakhir melakukan merge. Bisa saja saya tidak tahu selama seminggu bahwa update/build saya gagal, sampai maintainer yang baru ditambahkan memberi tahu lewat Matrix
    cache action terlihat jelas rusak hanya dari pengamatan, tetapi tampaknya tidak ada maintainer. Jika UI rusak atau tab ter-unload, kita bahkan tidak bisa men-tail log build dari suatu langkah. Hampir tidak ada abstraksi untuk membuat workflow portabel antar-node pekerja. Image default-nya nyaris bencana. Awalnya saya hanya kesal karena terlalu bloat, tetapi semakin digali, saya semakin berpikir, “ini pasti dipegang orang Microsoft yang tidak paham Linux.” Tidak ada upaya untuk menyediakan image yang lebih ringan bagi orang yang memakai Nix atau Docker. Saya sedang berpindah dari GitHub, dan alasan utamanya adalah Actions membuat saya benar-benar sadar. Alasan saya tidak memprogram dengan YAML adalah karena menurut saya YAML adalah aib yang lahir dari uang VC yang digelontorkan ke ekosistem yang tidak mengenal teknologi modern yang benar-benar berguna

    • Saat Microsoft mengakuisisi GitHub, bukankah sudah jelas hal seperti ini akan terjadi?

  • Saya sangat merekomendasikan https://pre-commit.ci. Saya bukan pihak terkait, hanya pengguna yang puas
    Idenya adalah menulis hook yang memeriksa kode sebelum commit dan memperbaikinya jika memungkinkan, atau memakai hook yang sudah ada; lalu setelah push, CI memeriksanya lagi dan bila perlu bahkan membuat commit perbaikan otomatis. Caching otomatisnya bagus sehingga luar biasa cepat, dan karena memakai konfigurasi yang sama di mesin pengembangan lokal maupun CI, masalah debugging jauh berkurang. Gratis untuk open source. Tidak melakukan hal seperti rilis otomatis, hanya pemeriksaan, tetapi pemeriksaannya dilakukan dengan sangat baik

    • Untuk proyek Python, ini sangat bagus jika dipakai bersama tox. tox membuat virtualenv sesuai versi Python yang ingin diuji dan menjalankan pengujian di dalamnya
      Untuk memeriksa source code itu sendiri, pemeriksaan statis juga bisa dijalankan dengan skip_install = True. Jalankan saja di container yang sudah memasang tox sebagai tool global dan berisi semua versi Python yang diperlukan. Misalnya ada image seperti https://github.com/georgek/docker-python-multiversion. Tidak dipelihara, tetapi mudah diperbarui. Boilerplate seperti menaruh [tox] envlist = py{310,311}, [testenv], dan pre-commit run --all-files --show-diff-on-failure di [testenv:check] sudah cukup

  • Setelah terlalu sering mengalami loop git commit; git push; repeat, saya menemukan https://github.com/mxschmitt/action-tmate. Ini membuka akses shell di antara tahap, jadi tidak menyelesaikan semua masalah, tetapi kadang benar-benar mengurangi rasa sakit

  • Secara pribadi, saya ingin bisa melampirkan laporan HTML ke action run tanpa harus memakai sesuatu seperti actions/upload-artifact saat ini
    Khususnya pada build pengujian, sering kali saya ingin cepat melihat laporan HTML output. Cara yang saya tahu sekarang adalah upload-artifact atau GH Pages, tetapi GH Pages kurang cocok ketika ada beberapa output laporan di repo yang sama, atau ketika ingin cepat melihat laporan lama alih-alih yang terbaru. Akan bagus jika ada action attach-report sederhana yang menambahkan tautan laporan HTML ke ringkasan job, lalu saat diklik merender HTML tersebut. Sistem otomatisasi CI/CD lain secara default menyediakan dukungan yang jauh lebih kaya untuk menangkap dan melihat laporan HTML

    • Memang bukan HTML, tetapi Anda bisa langsung menambahkan output Markdown ke $GITHUB_STEP_SUMMARY tanpa melalui upload artefak dan semacamnya

  • Menurut saya GH Actions pada dasarnya lebih mirip rebranding “Azure Pipelines” dari Microsoft. Sebagai orang yang pernah memakai semua bentuk lama pipeline build dan release TFS/VSTS/AzDO, tim ini tidak pandai mengerjakan hal ini
    Azure Pipelines baru menjadi lumayan bisa dipakai karena semua pendekatan yang mereka coba sebelumnya benar-benar gagal. Pernah juga ada proyek untuk menjalankan pipeline secara lokal agar loop edit-run-debug bisa dilakukan di lingkungan pribadi tanpa commit, tetapi tentu saja dibatalkan: https://github.com/microsoft/azure-pipelines-agent/pull/2687/files#diff-570b52bcb927a5365c22d17a21e8e19e1ba3427c7f3ec16ea64b7b3d14e4ee20. Meski begitu, ada tool yang meningkatkan kualitas hidup. Misalnya ekstensi VS Code yang mengenali sintaks: https://marketplace.visualstudio.com/items?itemName=ms-azure-devops.azure-pipelines. Sedikit kontroversial, tetapi seandainya mereka memakai XML alih-alih YAML, hanya dengan deklarasi xmlns di bagian atas saja kebanyakan editor kode yang layak bisa melakukan validasi tanpa intervensi pengguna tambahan. XML memang mengerikan, tetapi ada banyak fitur berguna yang ikut hilang ketika kita membuang semuanya

    • Setahu saya GHA adalah proyek yang sudah cukup jauh berjalan secara independen di internal GitHub sejak sebelum akuisisi Microsoft. Saya penasaran apakah maksudnya GHA dibuat ulang di atas AzP, sekadar AzP diberi nama baru, atau ada makna lain
    • Kemungkinannya lebih besar daripada yang dipikirkan kebanyakan orang. Setelah akuisisi, sebagian besar tim AzDo pindah mengerjakan GitHub Actions/Projects
    • Saya setuju sampai sebelum paragraf terakhir. XML bikin mata sakit. Daripada kengerian tanda kurung sudut dan camelCase, saya lebih memilih dokumen YAML yang diformat rapi meskipun tetap ada rasa sakitnya