Repo2docker-action: *バインダーハブ*でキャッシュをトリガーする機能を追加します

問題-ラベルボットは、0.97の信頼度で、この問題にラベルfeature_requestを自動的に適用します。 このコメントに：thumbsup：または：thumbsdown：のマークを付けて、ボットのフィードバックを提供してください。

リンク：アプリのホームページ、ダッシュボード、このボットのコード。

@choldgrafこれは素晴らしいアイデアです。 リンクを「訪問」することは、アクションに固有のものではないようです。プログラムでリンクを「訪問」する方法を理解する必要があります。binderhubにビルドをトリガーしてから取得できるAPIがあれば便利です。準備ができたらリンクしますか？ そのようなものは存在しますか？ それがなければ、私たちはセレンである種のハッキーなことをすることができるかもしれませんか？

あなたの考えを教えてください、私はそれが1つ少ないステップを含むのでバインダービルド割り当てをトリガーするというアイデアが好きです

バインダーハブにAPIがあり、ビルドをトリガーして、準備ができたらリンクを取得できると便利ですか？ そのようなものは存在しますか？

はい、そうです。 pyhfはこれを使用して、PRをマージするときにBinderビルドを自動的にトリガーするため、起動Binderバッジには常にユーザー用のビルド済みイメージがありますが、 @ betatimとの話し合いを正しく覚えていれば、これは正確には承認されていません。バインダーチーム。

@betatimは、このようなBinderビルドのトリガーが推奨されない理由についてさらに詳しく説明できますか？ 私たちが求めている理由は、このアクションの動作を最適化しようとしているためです。@ choldgrafは、 mybinder.orgの場合、このアクションのAPIをさらに単純化するためにbinderbuildをトリガーするのが最も簡単な方法であると指摘しています。

私たちが積極的にこれを行うように人々に勧めない理由は、この機能が大規模に使用される場合、何らかの形のレート制限を実装するか、「古いリビジョンの構築を停止する」必要があるためです。 リポジトリのメインブランチへのマージ時にビルドを自動的にトリガーする良心的な所有者がいる個々のリポジトリは問題ありません。すべてのPRのすべてのコミットでビルドをトリガーする洗浄されていない大衆は、mybinder.orgをすぐに圧倒します（一部のリポジトリはビルドに数時間のCPU時間を要します） 。

よく維持され、mybinder.org（メインブランチへのマージでの自動ビルド）に適した動作を実装するGHアクションを1つ持つことが、進むべき道だと思います。 別の方法は、ますます多くの人々がこれに賢明になり、独自のものを実装することです（この場合、個々のリポジトリを追跡する必要があります）。

追加のボーナスポイントについては、GHアクションが、CIでrepo2docker .のようなものを使用してローカルでイメージを構築するPRが「mybinder.orgで引き続き機能する」かどうかをテストする推奨方法も実装するとよいでしょう。 。 たぶん、PRコメントに、クリックするとバインダーを起動するリンクを投稿します（ただし、自動ビルドはしません）。

追加のクレジットとして、コンテナ内でスクリプトを実行してコードがまだ実行されているかどうかを確認する方法を提案することもできます（ repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynbのようなものを使用します）

したがって、全体として、これはmybinder.orgで共有できるコンピューティングリソースと、これが広く普及した場合に必要となる律速/不正使用防止機能を構築するために利用できる人材の問題です。 私はこれが存在することを望みます、そして少しの調整と協力でそれをやってのけることができると思います。

元の「API」コード： https ：//github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

わかりました、これは間違いなく扱いやすいものだと思います。 フィードバックを聞いた後の私の考え：

1. このアクションでこのAPIを呼び出しても問題ないようです（人々はそれを悪用する可能性がありますが、それは原則的なリスクだと思います）。
2. バインダーへのリンクを使用してPRにコメントする部分は、このアクションの外部で処理して、モジュール化を維持できます。 バインダーを使用するとこれが簡単になるため、次のようにワークフローに簡単に組み込むことができます。

この例は、先週のgithubブログでも取り上げられました。

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 }}

余談ですが、 @ betatimは、おそらく上記の例をバインダードキュメントに含める必要がありますか？

1. 追加のクレジットについて考える必要があります。 これは興味深いことです。repo2dockerが実行された後のダウンストリームステップになる可能性があるため、これをこのアクションに組み込むこともしないと思います。

ご不明な点やご意見がございましたら、お気軽にお問い合わせください。 mybinder.orgのキャッシュプロセスを簡素化するために、API呼び出しでベイク処理のプロセスを開始します。

@choldgraf私はこれを試しましたが、コンテナーを作成して独自のレジストリーにプッシュするのに比べて、ユーザーエクスペリエンスを楽しんでいません。 APIを使用しているときに問題が発生した場合、それはそれほど透過的ではありません。また、ビルドに時間がかかる理由や、ビルドがハングする原因もわかりません。 たとえば、このリポジトリで使用してみたところ、ビルド時間は実際にはかなり長いことがわかりました（アクションでのビルドと比較して）。その理由はわかりません。

今のところ、キャッシュする方法として独自のレジストリを使用してアクションを組み込むためのREADMEに関する推奨事項がありますが、mybinder.orgへの延期の例も示しています。

フィードバックやその他のアイデアを聞いてうれしいです

うーん、それは面白い。 もう少し詳しく教えていただけますか：

APIの使用時に問題が発生した場合、それはそれほど透過的ではありません

それはバインダーの問題ですか？ 改善するために、より良いエラーログが必要なものはありますか？

とりあえず、それもよくわかりません。 mybinder.orgはGoogleコンテナレジストリで実行されますが、Dockerhubよりも特に低速または高速で実行するべきではないと思います（？）。 Dockerhubがレイヤーなどをキャッシュしていた可能性がありますか？

一般に、カスタムの個人用レジストリを使用することは、Dockerに慣れていない人を対象としているため、Binderでは理想的ではないと思います。したがって、カスタムレジストリは、長期的な解決策としては優れているとは思いません（ただし、より技術的に精通していて、非常に役立つと思われる特定の研究者がいます！）