Libseccomp: BUG: pertimbangkan untuk mengganti Travis CI dengan tindakan GitHub

Berikut panduan untuk bermigrasi dari TravisCI ke Github Actions. Saya berharap untuk bereksperimen dengan ini selama beberapa hari ke depan
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-actions/migrating-from-travis-ci-to-github-actions

Saya sangat menyukai tampilan Github Actions. Saya baru saja mengirimkan patchset untuk mengganti libcgroup dari Travis CI ke Github Actions.

https://github.com/drakenclimber/libcgroup/tree/issues/github_actions
https://sourceforge.net/p/libcg/mailman/message/37165461/

Saya akan mencoba menyusun patchset untuk transisi libseccomp minggu ini.

Kedengarannya bagus @drakenclimber , terima kasih!

Berikut status saya saat ini. Saya memiliki Tindakan Github yang bekerja pada AMD64 dengan sedikit penyimpangan dari solusi Travis CI kami saat ini, tetapi saya memiliki kekhawatiran tentang arsitektur lain.

Kelebihan:

• Mudah digunakan. Saya dapat dengan cepat menyiapkan alur kerja integrasi berkelanjutan di Github Actions
• Ini juga mudah untuk mengenkapsulasi operasi menjadi sebuah tindakan . Tindakan ini kemudian dapat digunakan kembali dalam alur kerja. (Anehnya suatu tindakan tidak dapat meminta tindakan lain .)
• Kecepatan yang dapat diterima (setidaknya untuk amd64). Seluruh rangkaian tes selesai dalam 22 menit
• GUI yang baik dan langkah-langkah yang gagal digambarkan dengan jelas
• Saya sangat menyukai opsi paralelisasi Github Actions, dan ini menyediakan fitur untuk menyusun hasil setelah pekerjaan lain selesai. Saya menggunakan fitur ini di libcgroup untuk menyelesaikan nomor cakupan kodenya setelah semua tes berjalan

Kontra:

• Tidak ada dukungan asli untuk arsitektur lain
  
  
  
  • Seorang karyawan github memberikan solusi ini untuk menjalankan container Docker arm64. Saya mencobanya, dan dengan sedikit mengutak-atik saya bisa mendapatkan rangkaian tes dasar yang sebagian besar berfungsi. (Uji 52 - beban dasar - gagal untuk beberapa alasan aneh.) Tetapi pengaturan ini sulit untuk direproduksi secara lokal dan debugging merupakan tantangan yang signifikan. Saya tidak dapat menjalankan tes python. Oh, dan ini sangat, sangat lambat - butuh satu jam untuk menjalankan serangkaian tes yang dikupas di arm64. ppc64el membutuhkan waktu 6 jam sebelum saya membunuhnya :(
  
  
  • Pengguna github membuat tindakan ini yang juga menggunakan wadah Docker untuk menjalankan arsitektur non-asli. Sintaksnya agak kikuk dan mengharuskan kita untuk menggandakan kode. Arsitektur dan daftar platform yang didukungnya cukup bagus
  
  
  • Github Actions mendukung penggunaan runner yang dihosting sendiri , jadi satu opsi (jelek) adalah menemukan kotak arm64, ppc64le, dll. khusus dan menggunakannya untuk menjalankan tes. Keuntungan dari ini adalah bahwa debugging akan jauh lebih mudah daripada wadah Docker
  
  

Lainnya:

• Coveralls.io telah membuat Github Action . Solusi TravisCI kami yang ada, cpp-coveralls , berfungsi pada Github Actions tetapi kesulitan dengan build paralel. Saya memiliki tindakan Coveralls yang bekerja secara paralel di libcgroup
• Untuk memanfaatkan tindakan Coveralls, saya harus memanggil lcov secara langsung untuk menghasilkan file lcov.info. File ini kemudian diunggah ke coveralls.io. Perhatikan bahwa menggunakan lcov secara langsung menghasilkan nomor cakupan yang sedikit berbeda. Misalnya, solusi Travis CI tidak menentukan apakah baris ini tercakup atau tidak, sementara solusi Github Actions secara eksplisit menyebutnya tidak terungkap . Saya percaya Tindakan Github benar dalam kasus ini dan solusi kami saat ini sedikit salah melaporkan nomor cakupannya
• Catatan untuk diri sendiri - Saya tidak memiliki tanda lcov --exclude src/arch-syscall-check.c berfungsi. Tidak tahu kenapa

Berikut status saya saat ini. Saya memiliki Tindakan Github yang bekerja pada AMD64 dengan sedikit penyimpangan dari solusi Travis CI kami saat ini, tetapi saya memiliki kekhawatiran tentang arsitektur lain.

Kelebihan:

• Mudah digunakan. Saya dapat dengan cepat menyiapkan alur kerja integrasi berkelanjutan di Github Actions
• Ini juga mudah untuk mengenkapsulasi operasi menjadi sebuah tindakan . Tindakan ini kemudian dapat digunakan kembali dalam alur kerja. (Anehnya suatu tindakan tidak dapat meminta tindakan lain .)
• Kecepatan yang dapat diterima (setidaknya untuk amd64). Seluruh rangkaian tes selesai dalam 22 menit
• GUI yang baik dan langkah-langkah yang gagal digambarkan dengan jelas
• Saya sangat menyukai opsi paralelisasi Github Actions, dan ini menyediakan fitur untuk menyusun hasil setelah pekerjaan lain selesai. Saya menggunakan fitur ini di libcgroup untuk menyelesaikan nomor cakupan kodenya setelah semua tes berjalan

Kontra:

• Tidak ada dukungan asli untuk arsitektur lain

  • Seorang karyawan github memberikan solusi ini untuk menjalankan container Docker arm64. Saya mencobanya, dan dengan sedikit mengutak-atik saya bisa mendapatkan rangkaian tes dasar yang sebagian besar berfungsi. (Uji 52 - beban dasar - gagal untuk beberapa alasan aneh.) Tetapi pengaturan ini sulit untuk direproduksi secara lokal dan debugging merupakan tantangan yang signifikan. Saya tidak dapat menjalankan tes python. Oh, dan ini sangat, sangat lambat - butuh satu jam untuk menjalankan serangkaian tes yang dikupas di arm64. ppc64el membutuhkan waktu 6 jam sebelum saya membunuhnya :(
  • Pengguna github membuat tindakan ini yang juga menggunakan wadah Docker untuk menjalankan arsitektur non-asli. Sintaksnya agak kikuk dan mengharuskan kita untuk menggandakan kode. Arsitektur dan daftar platform yang didukungnya cukup bagus
  • Github Actions mendukung penggunaan runner yang dihosting sendiri , jadi satu opsi (jelek) adalah menemukan kotak arm64, ppc64le, dll. khusus dan menggunakannya untuk menjalankan tes. Keuntungan dari ini adalah bahwa debugging akan jauh lebih mudah daripada wadah Docker

Lainnya:

• Coveralls.io telah membuat Github Action . Solusi TravisCI kami yang ada, cpp-coveralls , berfungsi pada Github Actions tetapi kesulitan dengan build paralel. Saya memiliki tindakan Coveralls yang bekerja secara paralel di libcgroup
• Untuk memanfaatkan tindakan Coveralls, saya harus memanggil lcov secara langsung untuk menghasilkan file lcov.info. File ini kemudian diunggah ke coveralls.io. Perhatikan bahwa menggunakan lcov secara langsung menghasilkan nomor cakupan yang sedikit berbeda. Misalnya, solusi Travis CI tidak menentukan apakah baris ini tercakup atau tidak, sementara solusi Github Actions secara eksplisit menyebutnya tidak terungkap . Saya percaya Tindakan Github benar dalam kasus ini dan solusi kami saat ini sedikit salah melaporkan nomor cakupannya
• Catatan untuk diri sendiri - Saya tidak memiliki tanda lcov --exclude src/arch-syscall-check.c berfungsi. Tidak tahu kenapa

Bagaimana dengan menggunakan Vagrant di macOS?

Bagaimana dengan menggunakan Vagrant di macOS?

Masalah ini secara khusus tentang memindahkan pengujian CI kami dari Travis CI ke GitHub Actions dan bukan pengembangan dan pengujian umum libseccomp. Saya tidak yakin MacOS adalah pilihan untuk GitHub Actions, dan bahkan jika itu pilihan yang buruk bagi kami karena kurangnya dukungan kernel (tes "langsung" kami terbatas, tetapi penting).

Berikut status saya saat ini. Saya memiliki Tindakan Github yang bekerja pada AMD64 dengan sedikit penyimpangan dari solusi Travis CI kami saat ini, tetapi saya memiliki kekhawatiran tentang arsitektur lain.

Terima kasih telah melihat ke @drakenclimber ini, dukungan arsitektur yang terbatas sangat mengecewakan. Karena kami sebenarnya tidak melihat banyak masalah dengan Travis CI saat ini, mungkin kami melanjutkan dengan Travis sampai menjadi mengganggu?

Mengenai komentar lcov/Coveralls; Saya telah memperhatikan hal-hal serupa di masa lalu, tetapi tidak terlalu khawatir tentang perbedaannya karena itu kecil. Saya ingin tahu apakah mungkin menggunakan lcov di Travis dan mengunggah file lcov sebagai bagian dari pembuatan Travis tanpa membocorkan kredensial apa pun di konfigurasi Travis? Jika tidak ada hal lain yang akan membawa konsistensi di seluruh penggunaan lokal dan Travis, dan itu mungkin membuat segalanya sedikit lebih mudah jika/ketika kita bermigrasi jauh dari Travis CI.

Bagaimana dengan menggunakan Vagrant di macOS?

Masalah ini secara khusus tentang memindahkan pengujian CI kami dari Travis CI ke GitHub Actions dan bukan pengembangan dan pengujian umum libseccomp. Saya tidak yakin MacOS adalah pilihan untuk GitHub Actions, dan bahkan jika itu pilihan yang buruk bagi kami karena kurangnya dukungan kernel (tes "langsung" kami terbatas, tetapi penting).

Saya cukup akrab dengan GitHub Actions. Mereka mendukung macOS (Lihat: https://github.com/actions/virtual-environments#available-environments). Secara khusus, macOS adalah satu-satunya lingkungan yang hadir dengan Vagrant dan VirtualBox (Lihat: https://github.com/actions/virtual-environments/issues/433).

Dalam pengalaman saya, ini membutuhkan sedikit lebih banyak pekerjaan untuk disiapkan, tetapi berjalan di dalam mesin virtual memastikan lingkungan yang lebih konsisten untuk saluran pipa CI/CD. Belum lagi, ini lebih portabel, karena siapa pun dapat menjalankan gambar Vagrant/VirtualBox secara lokal. Ini juga membuat migrasi ke solusi CI/CD baru lebih mudah, karena konfigurasi biasanya ditulis dalam skrip, terlepas dari deklarasi YAML khusus vendor.

Ini hanya dua sen saya :)

Terima kasih @oxr463 , itu bagus untuk diketahui tentang GH Actions. Pada titik ini saya lebih suka untuk tidak memiliki overhead manajemen ekstra dari lingkungan virtual, tetapi itu adalah sesuatu yang perlu dipertimbangkan jika Travis CI pernah menjadi masalah bagi kami.

Karena aktivitas Travis kami relatif ringan, saya harap kami tidak akan mengalami masalah Travis seperti yang pernah dialami beberapa proyek lain.

Terima kasih telah melihat ke @drakenclimber ini, dukungan arsitektur yang terbatas sangat mengecewakan. Karena kami sebenarnya tidak melihat banyak masalah dengan Travis CI saat ini, mungkin kami melanjutkan dengan Travis sampai menjadi mengganggu?

Ya, saya pikir itu jawaban terbaik dan teraman.

Mengenai komentar lcov/Coveralls; Saya telah memperhatikan hal-hal serupa di masa lalu, tetapi tidak terlalu khawatir tentang perbedaannya karena itu kecil. Saya ingin tahu apakah mungkin menggunakan lcov di Travis dan mengunggah file lcov sebagai bagian dari pembuatan Travis tanpa membocorkan kredensial apa pun di konfigurasi Travis? Jika tidak ada hal lain yang akan membawa konsistensi di seluruh penggunaan lokal dan Travis, dan itu mungkin membuat segalanya sedikit lebih mudah jika/ketika kita bermigrasi jauh dari Travis CI.

Ya, ini harus mungkin. Saya membuat Edisi #309 dan menetapkannya untuk diri saya sendiri. Saya akan mencoba untuk mengambil ini dalam satu atau dua minggu ke depan.

Terima kasih

Dalam pengalaman saya, ini membutuhkan sedikit lebih banyak pekerjaan untuk disiapkan, tetapi berjalan di dalam mesin virtual memastikan lingkungan yang lebih konsisten untuk saluran pipa CI/CD. Belum lagi, ini lebih portabel, karena siapa pun dapat menjalankan gambar Vagrant/VirtualBox secara lokal. Ini juga membuat migrasi ke solusi CI/CD baru lebih mudah, karena konfigurasi biasanya ditulis dalam skrip, terlepas dari deklarasi YAML khusus vendor.

Terima kasih, @oxr463. Saya juga berharap kita tidak harus menempuh rute itu, tetapi ada baiknya mengetahui bahwa ada pilihan lain di luar sana.

@drakenclimber Saya akan menjatuhkan ini dari tonggak rilis dan menurunkan prioritas ke rendah karena kami mengadopsi pendekatan "tunggu sampai rusak" untuk ini, jika Anda tidak setuju, jangan ragu untuk berteriak atau sesuaikan labelnya.

@drakenclimber Saya akan menjatuhkan ini dari tonggak rilis dan menurunkan prioritas ke rendah karena kami mengadopsi pendekatan "tunggu sampai rusak" untuk ini, jika Anda tidak setuju, jangan ragu untuk berteriak atau sesuaikan labelnya.

Terdengar bagus untukku. Terima kasih!

@drakenclimber satu hal baru saja terpikir oleh saya - kita harus mempertimbangkan untuk mencoba bermigrasi dari travis-ci.org ke travis-ci.com karena ".org" seharusnya akan hilang "dalam beberapa minggu".

Oh! Tidak tahu itu. Terima kasih!

Saya akan mencoba untuk mengambil ini minggu depan kemudian.