New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the ability to trigger a cache *on a binderhub* #25
Comments
Issue-Label Bot is automatically applying the label 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 |
Yes, it does. |
@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 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 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:
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?
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:
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!) |
I was thinking about other ways that this action could improve people's workflows with Binder, and it got me thinking that it could also be used to trigger a build on a specific BinderHub.
For example, once a commit has been pushed to a repository, all that needs to happen is for somebody to hit
https://<mybinderhub.org>/v2/gh/org/repo/master
, and it will trigger the repository to both build and cache with that BinderHub's Docker registry. Is there a way to have a GitHub action "visit" a specific URL to automatically trigger this build?This could be a cleaner way to handle repositories that are expected to run on a specific BinderHub (like
mybinder.org
), and also doesn't require any manual interaction with a Docker registry (since that would be done by the BinderHub)Perhaps this is an action that we should host in the jupyterhub repository, since it's more BinderHub-specific? I'd be happy to try implementing it myself if you could point me in the right direction, or to review a PR / repo that someone else creates.
The text was updated successfully, but these errors were encountered: