Repo2docker-action: Add the ability to trigger a cache *on a binderhub*

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.97. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

@choldgraf this is an excellent idea. "visiting" a link doesn't seem like something specific to an action, we just have to figure out how to "visit" the link programmatically, it would be nice if binderhub had an API whereby you could trigger a build and then get a link when its ready? Does such a thing exist? In the absence of that, we might be able to do some kind of hacky thing with selenium?

Let me know your thoughts, I like the idea of triggering a binder build allot as it involves one less step

it would be nice if binderhub had an API whereby you could trigger a build and then get a link when its ready? Does such a thing exist?

Yes, it does. pyhf uses this to automatically trigger Binder builds when we merge PRs so that our launch Binder badge always has a pre-built image for users, but if I remember discussions with @betatim correctly, this isn't exactly endorsed by the Binder team.

@betatim can you expand more about why triggering Binder builds like this is not encouraged? The reason we are asking is that we are trying to optimize the way this Action works, and @choldgraf points out that for mybinder.org the easiest way would be to trigger a binderbuild to further simplify the API of this Action.

The reason we don't actively encourage people to do this is that we'd have to implement some form of rate limiting or "stop building old revisions" if this feature is used at scale. Individual repositories with conscientious owners that trigger a build automatically on merge into main branch of the repo is fine, the unwashed masses triggering a build on every commit in every PR will quickly overwhelm mybinder.org (some repos take hours of CPU time to build).

I think having one GH action that is well maintained and implements the behaviour that is good for mybinder.org (auto build on merge to main branch) is the way to go. The alternative is that more and more people get wise to this and implement their own thing (in which case we have to go track down individual repos).

For extra bonus points it would be nice if the GH action also implemented our recommended way of testing if your PR "still works on mybinder.org" which is to use something like repo2docker . in your CI to build an image locally. Maybe posting a link in the PR comment that would launch a Binder if you clicked it (but doesn't auto build it).

For extra extra credit we could even suggest to people how to run a script inside the container to check if their code still runs (I use something like repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb)

So overall this is a question of compute resources that are available on mybinder.org for people to share and human resources available to build the rate limiting/anti-abuse features we'd need if this becomes wide spread. I want this to exist and with a bit of coordination&cooperation I think we can pull it off.

The original "API" code: https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

ok I think this is definitely a tractable thing. My thoughts after hearing the feedback:

1. It sounds like its ok to call this API in this Action (people could still abuse it, but I suppose it is a principled risk).
2. The part about commenting on the PR with a link to Binder can be handled outside this Action to keeps things modular. Binder makes this easy, so it is easy to incorporate into your workflow like this:

This example was also featured in the github blog last week!

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

aside: @betatim perhaps the above example should be in the Binder Docs?

1. I'll have to think about the extra credit. That is interesting, I think I would also not bake that into this Action as that could be a downstream step after repo2docker runs.

Please let me know if there are any questions or feedback. I'll start the process of baking in the API call to simplify the mybinder.org caching process.

@choldgraf I tried this but do not enjoy the user experience compared to building the container and pushing it to your own registry. When things fail when using the API it is not as transparent, also you don't know why the build is taking a long time or what is causing it to hang. I tried using it for this repo, for example and found that the build time is actually quite long (compared to building in Actions) -- not sure why that is.

For right now I have a recommendation on the README for folks to build in Actions with their own registry as a way to cache, but also show an example of deferring to mybinder.org

Happy to hear any feedback or more ideas

Hmmm - that's interesting. Could you expand a bit more on:

When things fail when using the API it is not as transparent

Is that a Binder issue? Something that needs better error logging to improve upon?

For the time, that's also one I'm not sure about. mybinder.org runs on the google container registry, which I think (?) shouldn't run particularly slower or faster than Dockerhub. Could it be that the Dockerhub had cached layers or something like this?

I do think that, in general, using a custom personal registry is not ideal with Binder as it is geared towards people who are unfamiliar with Docker, so I don't think that custom registries is a great long-term solution (though I think there are certain researchers who are more technically savvy that will find it very useful!)