Repo2docker-action: 添加在 binderhub 上触发缓存的功能*

Issue-Label Bot 自动将标签feature_request应用于此问题，置信度为 0.97。 请用 :thumbsup: 或 :thumbsdown: 标记此评论，以提供我们的机器人反馈！

链接：此机器人的应用主页、仪表板和代码。

@choldgraf这是一个绝妙的主意。 “访问”链接似乎不是特定于操作的东西，我们只需要弄清楚如何以编程方式“访问”链接，如果 binderhub 有一个 API 可以触发构建然后获取链接什么时候准备好？ 这样的事情存在吗？ 如果没有这个，我们也许可以用selenium做一些 hacky 的事情？

让我知道你的想法，我喜欢触发活页夹构建分配的想法，因为它涉及的步骤更少

如果 binderhub 有一个 API，您可以触发构建，然后在它准备好时获取链接，那会很好吗？ 这样的事情存在吗？

是的，它确实。 pyhf使用它在我们合并 PR 时自动触发 Binder 构建，以便我们的启动 Binder 徽章始终为用户提供预先构建的图像，但如果我没记错与@betatim的讨论，这并没有得到完全认可粘合剂团队。

@betatim您能否详细说明为什么不鼓励像这样触发 Binder 构建？ 我们询问的原因是我们正在尝试优化此 Action 的工作方式， @choldgraf指出，对于 mybinder.org，最简单的方法是触发 binderbuild 以进一步简化此 Action 的 API。

我们不积极鼓励人们这样做的原因是，如果大规模使用此功能，我们将不得不实施某种形式的速率限制或“停止构建旧版本”。 具有良心所有者的个人存储库在合并到 repo 的主分支时自动触发构建很好，未清洗的群众在每个 PR 的每次提交上触发构建将很快压倒 mybinder.org（一些 repo 需要数小时的 CPU 时间来构建） .

我认为拥有一个维护良好的 GH 操作并实现对 mybinder.org 有益的行为（在合并到主分支时自动构建）是可行的方法。 另一种选择是越来越多的人对此变得明智并实施他们自己的事情（在这种情况下，我们必须去追踪个人回购）。

对于额外的奖励积分，如果 GH 操作也实施我们推荐的测试您的 PR 是否“在 mybinder.org 上仍然有效”的方法，那就太好了，即在您的 CI 中使用类似repo2docker .的东西在本地构建图像. 也许在 PR 评论中发布一个链接，如果您单击它会启动一个 Binder（但不会自动构建它）。

为了获得额外的积分，我们甚至可以向人们建议如何在容器内运行脚本以检查他们的代码是否仍然运行（我使用类似repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb的东西）

所以总的来说，这是一个关于 mybinder.org 上可供人们共享的计算资源和用于构建我们需要的速率限制/反滥用功能的人力资源的问题，如果这变得广泛传播。 我希望它存在，并且通过一些协调与合作，我认为我们可以实现它。

原始“API”代码： https ://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

好的，我认为这绝对是一件容易处理的事情。 听完反馈后的感想：

1. 在这个 Action 中调用这个 API 听起来是可以的（人们仍然可以滥用它，但我认为这是一个原则性风险）。
2. 关于通过 Binder 链接评论 PR 的部分可以在此 Action 之外处理，以保持模块化。 Binder 使这很容易，因此很容易像这样将其合并到您的工作流程中：

这个例子也出现在上周的 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也许上面的例子应该在 Binder Docs 中？

1. 我将不得不考虑额外的信用。 这很有趣，我认为我也不会将其纳入此 Action，因为这可能是 repo2docker 运行后的下游步骤。

如果有任何问题或反馈，请告诉我。 我将在 API 调用中开始烘焙过程以简化 mybinder.org 缓存过程。

@choldgraf我尝试了这个，但与构建容器并将其推送到您自己的注册表相比，不喜欢用户体验。 当使用 API 失败时，它不那么透明，您也不知道为什么构建需要很长时间或导致它挂起的原因。 例如，我尝试将它用于这个 repo，发现构建时间实际上很长（与在 Actions 中构建相比）——不知道为什么会这样。

现在我有一个关于 README 的建议，供人们使用他们自己的注册表构建 Actions 作为缓存的一种方式，但也展示了一个推迟到 mybinder.org 的示例

很高兴听到任何反馈或更多想法

嗯——这很有趣。 您能否进一步扩展：

当使用 API 失败时，它就不那么透明了

这是Binder的问题吗？ 需要更好的错误记录来改进的东西？

目前，这也是我不确定的一个。 mybinder.org 在 google 容器注册表上运行，我认为（？）不应该比 Dockerhub 运行得特别慢或快。 会不会是 Dockerhub 有缓存层或类似的东西？

我确实认为，总的来说，使用自定义的个人注册表对于 Binder 并不理想，因为它面向不熟悉 Docker 的人，所以我不认为自定义注册表是一个很好的长期解决方案（尽管我认为有些研究人员更精通技术，会发现它非常有用！）