Libseccomp: RFE: Transisi dari travis-ci.org ke travis-ci.com

Dibuat pada 19 Jan 2021  ·  10Komentar  ·  Sumber: seccomp/libseccomp

travis-ci.org sedang dinonaktifkan dan akan ditiadakan dalam waktu dekat.

Ikuti langkah-langkah di sini untuk mentransisikan libseccomp ke situs travis-ci.com yang baru.
https://docs.travis-ci.com/user/migrate/open-source-repository-migration

enhancement priorithigh

Semua 10 komentar

Saya login ke travis-ci.com, tetapi masih dalam tahap beta, jadi kami belum bisa melakukan transisi.

Bah! Mereka pasti tidak membuat ini mudah bukan? ;)

Karena batas waktu transisi masih "kabur" untuk membuatnya lebih halus, saya akan menarik ini dari tonggak v2.5.2 dan membiarkannya mengambang. Kita masih perlu melihat ini di beberapa titik, tetapi sampai Travis bergerak, tidak ada yang bisa kita lakukan di sini.

Saya baru saja pergi untuk memverifikasi bahwa pembangunan Travis selesai dengan baik setelah beberapa dorongan dan saya disambut oleh pesan ini:

Sejak 15 Juni 2021, pembangunan di travis-ci.org dihentikan. Silakan gunakan travis-ci.com mulai sekarang.

... sepertinya kita perlu mencari tahu ini, dan segera.

Saya agak curiga dengan model bisnis baru Travis. Sepertinya open source akan tetap gratis (untuk saat ini), tetapi mereka tidak membuatnya mudah. Kami mungkin perlu meminta lebih banyak "kredit" dari mereka secara berkala.
https://docs.travis-ci.com/user/billing-faq/#what -if-i-am-building-open-source

What if I am building open source? #

Each of the Travis CI Plans contains an amount of special OSS credits per month assigned to
run builds only on public repositories. To find out more about it please contact the Travis CI
support team. In the email please include:

* Your account name and your VCS provider (like travis-ci.com/github/[your account name] )
* How many credits (build minutes) you’d like to request (should your run out of credits again
  you can repeat the process to request more or to discuss a renewable amount)

Ugh, menyebalkan :/

Saya perlu menyegarkan ingatan saya tentang apa yang Anda ketahui tentang GH Actions; itu jauh dari sempurna, tetapi mengingat perubahan Travis CI, itu mungkin pilihan yang lebih baik.

Ini dia... #299

Oke, setelah menyegarkan ingatan saya di #299, saya pikir opsi terbaik saat ini adalah bermigrasi ke GH Actions dan tetap menggunakan x86_64 CI build untuk saat ini. Itu sepertinya jalur tercepat untuk memulihkan PR/cabang dan tes cakupan kode dengan sedikit sakit kepala.

Kurangnya lengkungan/ABI lain mengganggu, tetapi secara realistis kami tidak menguji setiap lengkungan/ABI secara teratur (bagaimana bisa?) jadi ini bukan akhir dari dunia. Jika itu membantu, meskipun bukan "CI", saya memiliki pekerjaan malam yang berjalan di beberapa infrastruktur pribadi yang membangun dan memverifikasi cabang utama libseccomp di aarch64; jika ada yang rusak, saya akan melihatnya dalam ~ 24 jam. Semoga kita bisa menemukan sesuatu yang lebih baik di masa depan (saya punya beberapa ide di sini ...).

pikiran @drakenclimber ?

Saya pikir opsi terbaik saat ini adalah bermigrasi ke GH Actions dan tetap menggunakan x86_64 CI build untuk saat ini. Itu sepertinya jalur tercepat untuk memulihkan PR/cabang dan tes cakupan kode dengan sedikit sakit kepala.

Terdengar bagus untukku. Saya dapat memiliki transisi karena saya sudah melakukannya untuk libcgroup.

Kami telah menggunakan Tindakan Github di libcgroup cukup lama sekarang, dan itu bekerja dengan cukup baik. Pekerjaan mudah dipindahkan dari Travis.

Github Actions VMs tidak menyediakan fitur yang kami butuhkan di libcgroup (sistem cgroup v2 lengkap), jadi saya baru-baru ini membuat VM di Oracle Free Cloud dan menghubungkannya melalui runner yang dihosting sendiri oleh Github Actions. Itu mudah diatur, dan sejauh ini telah bekerja dengan baik. Saya percaya logika GH Actions self-hosted-runner mendukung aarch64, jadi ini bisa menjadi cara untuk terus menguji ARM jika kami memiliki kotak yang bisa kami arahkan.

Kurangnya lengkungan/ABI lain mengganggu, tetapi secara realistis kami tidak menguji setiap lengkungan/ABI secara teratur (bagaimana bisa?) jadi ini bukan akhir dari dunia.

Sepakat. Saya menyukai berbagai arsitektur yang saat ini diuji karena kadang-kadang ditemukan masalah 32- vs 64-bit dan big-vs little-endian yang aneh. Sebelum rilis, kita harus (minimal) menjalankan tes di arsitektur lain. Mungkin kita bisa merekrut kontributor masa lalu untuk membantu di sini.

(Saya punya beberapa ide di sini ...).

Saya mendengarkan. Saya berharap saya bisa mengambil bagian terbaik dari GH Actions dan Travis dan memasukkannya ke dalam satu CI.

(Saya punya beberapa ide di sini ...)

Maaf, saya seharusnya lebih jelas. Maksud saya, saya mungkin memiliki beberapa ide untuk mendukung aarch64, bukan tentang Travis/GH secara umum.

Bagaimanapun, terima kasih telah mengerjakan ini di PR #329.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat