Repo2docker-action: Tambahkan kemampuan untuk memicu cache *pada binderhub*

Bot Label Masalah secara otomatis menerapkan label feature_request ke masalah ini, dengan keyakinan 0,97. Harap tandai komentar ini dengan :thumbsup: atau :thumbsdown: untuk memberikan umpan balik bot kami!

Tautan: beranda aplikasi , dasbor , dan kode untuk bot ini.

@choldgraf ini adalah ide yang bagus. "mengunjungi" tautan sepertinya bukan sesuatu yang spesifik untuk suatu tindakan, kita hanya perlu mencari cara untuk "mengunjungi" tautan secara terprogram, alangkah baiknya jika binderhub memiliki API yang dengannya Anda dapat memicu pembangunan dan kemudian mendapatkan linknya kapan ready? Apakah hal seperti itu ada? Dengan tidak adanya itu, kita mungkin dapat melakukan semacam peretasan dengan Selenium ?

Beri tahu saya pendapat Anda, saya suka ide memicu alokasi build binder karena melibatkan satu langkah lebih sedikit

alangkah baiknya jika binderhub memiliki API tempat Anda dapat memicu build dan kemudian mendapatkan tautan saat sudah siap? Apakah hal seperti itu ada?

Ya, memang. pyhf menggunakan ini untuk memicu pembuatan Binder secara otomatis saat kami menggabungkan PR sehingga lencana Binder peluncuran kami selalu memiliki gambar bawaan untuk pengguna, tetapi jika saya mengingat diskusi dengan @betatim dengan benar, ini tidak sepenuhnya didukung oleh tim Pengikat.

@betatim dapatkah Anda memperluas lebih lanjut tentang mengapa memicu build Binder seperti ini tidak dianjurkan? Alasan kami menanyakannya adalah karena kami mencoba mengoptimalkan cara kerja Tindakan ini, dan @choldgraf menunjukkan bahwa untuk mybinder.org cara termudah adalah memicu binderbuild untuk lebih menyederhanakan API Tindakan ini.

Alasan kami tidak secara aktif mendorong orang untuk melakukan ini adalah karena kami harus menerapkan beberapa bentuk pembatasan tarif atau "berhenti membuat revisi lama" jika fitur ini digunakan dalam skala besar. Repositori individu dengan pemilik teliti yang memicu build secara otomatis saat bergabung ke cabang utama repo baik-baik saja, massa yang tidak dicuci yang memicu build pada setiap komit di setiap PR akan dengan cepat membanjiri mybinder.org (beberapa repo membutuhkan waktu berjam-jam CPU untuk membangun) .

Saya pikir memiliki satu tindakan GH yang terpelihara dengan baik dan mengimplementasikan perilaku yang baik untuk mybinder.org (pembuatan otomatis pada penggabungan ke cabang utama) adalah cara yang harus dilakukan. Alternatifnya adalah semakin banyak orang menjadi bijak dalam hal ini dan menerapkan hal mereka sendiri (dalam hal ini kita harus melacak repo individu).

Untuk poin bonus tambahan, alangkah baiknya jika tindakan GH juga menerapkan cara pengujian yang kami rekomendasikan jika PR Anda "masih berfungsi di mybinder.org" yaitu menggunakan sesuatu seperti repo2docker . di CI Anda untuk membuat gambar secara lokal . Mungkin memposting tautan di komentar PR yang akan meluncurkan Binder jika Anda mengkliknya (tetapi tidak membuatnya secara otomatis).

Untuk kredit ekstra tambahan, kami bahkan dapat menyarankan kepada orang-orang cara menjalankan skrip di dalam wadah untuk memeriksa apakah kode mereka masih berjalan (saya menggunakan sesuatu seperti repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb )

Jadi secara keseluruhan ini adalah pertanyaan tentang sumber daya komputasi yang tersedia di mybinder.org untuk dibagikan kepada orang-orang dan sumber daya manusia yang tersedia untuk membangun fitur pembatasan kecepatan/anti-penyalahgunaan yang kami perlukan jika ini tersebar luas. Saya ingin ini ada dan dengan sedikit koordinasi & kerjasama saya pikir kita bisa melakukannya.

Kode "API" asli: https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

ok saya pikir ini pasti hal yang penurut. Pikiran saya setelah mendengar umpan balik:

1. Sepertinya tidak apa-apa untuk memanggil API ini dalam Tindakan ini (orang masih bisa menyalahgunakannya, tapi saya kira itu adalah risiko berprinsip).
2. Bagian tentang mengomentari PR dengan tautan ke Binder dapat ditangani di luar Tindakan ini untuk menjaga semuanya tetap modular. Binder membuatnya mudah, sehingga mudah untuk dimasukkan ke dalam alur kerja Anda seperti ini:

Contoh ini juga ditampilkan di blog github minggu lalu!

name: Binder
on: 
  pull_request:
    types: [opened, reopened]

jobs:
  Create-Binder-Badge:
    runs-on: ubuntu-latest
    steps:
    - name: comment on PR with Binder link
      uses: actions/github-script<strong i="11">@v1</strong>
      with:
        github-token: ${{secrets.GITHUB_TOKEN}}
        script: |
          var BRANCH_NAME = process.env.BRANCH_NAME;
          github.issues.createComment({
            issue_number: context.issue.number,
            owner: context.repo.owner,
            repo: context.repo.repo,
            body: `[![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/${context.repo.owner}/${context.repo.repo}/${BRANCH_NAME}) :point_left: Launch a binder notebook on this branch`
          }) 
      env:
        BRANCH_NAME: ${{ github.event.pull_request.head.ref }}

samping: @betatim mungkin contoh di atas harus ada di Binder Docs?

1. Saya harus memikirkan kredit ekstra. Itu menarik, saya pikir saya juga tidak akan memasukkannya ke dalam Tindakan ini karena itu bisa menjadi langkah hilir setelah repo2docker berjalan.

Tolong beri tahu saya jika ada pertanyaan atau umpan balik. Saya akan memulai proses memanggang dalam panggilan API untuk menyederhanakan proses caching mybinder.org.

@choldgraf Saya mencoba ini tetapi tidak menikmati pengalaman pengguna dibandingkan dengan membangun wadah dan mendorongnya ke registri Anda sendiri. Ketika semuanya gagal saat menggunakan API, itu tidak setransparan, Anda juga tidak tahu mengapa pembangunan memakan waktu lama atau apa yang menyebabkannya macet. Saya mencoba menggunakannya untuk repo ini, misalnya dan menemukan bahwa waktu pembuatan sebenarnya cukup lama (dibandingkan dengan membangun dalam Tindakan) -- tidak yakin mengapa demikian.

Untuk saat ini saya memiliki rekomendasi tentang README bagi orang-orang untuk membangun Tindakan dengan registri mereka sendiri sebagai cara untuk menyimpan cache, tetapi juga menunjukkan contoh penangguhan ke mybinder.org

Senang mendengar umpan balik atau lebih banyak ide

Hmm - itu menarik. Bisakah Anda memperluas sedikit lebih banyak tentang:

Ketika semuanya gagal saat menggunakan API, itu tidak setransparan

Apakah itu masalah Binder? Sesuatu yang membutuhkan logging kesalahan yang lebih baik untuk diperbaiki?

Untuk saat ini, itu juga salah satu yang saya tidak yakin. mybinder.org berjalan di registri wadah google, yang menurut saya (?) tidak boleh berjalan lebih lambat atau lebih cepat daripada Dockerhub. Mungkinkah Dockerhub memiliki lapisan cache atau semacamnya?

Saya pikir, secara umum, menggunakan registri pribadi khusus tidak ideal dengan Binder karena ditujukan untuk orang-orang yang tidak terbiasa dengan Docker, jadi saya tidak berpikir bahwa pendaftar khusus adalah solusi jangka panjang yang bagus (walaupun saya pikir ada peneliti tertentu yang lebih paham secara teknis yang akan merasa sangat berguna!)