Repo2docker-action: Fügen Sie die Möglichkeit hinzu, einen Cache *auf einem Binderhub* auszulösen

Issue-Label Bot wendet automatisch das Label feature_request auf dieses Problem an, mit einer Konfidenz von 0,97. Bitte markiere diesen Kommentar mit :thumbsup: oder :thumbsdown: um unserem Bot Feedback zu geben!

Links: App-Homepage , Dashboard und Code für diesen Bot.

@choldgraf , das ist eine ausgezeichnete Idee. Das „Besuchen“ eines Links scheint nicht spezifisch für eine Aktion zu sein, wir müssen nur herausfinden, wie wir den Link programmgesteuert „besuchen“ können. Es wäre schön, wenn binderhub eine API hätte, mit der Sie einen Build auslösen und dann einen erhalten könnten Link, wenn es fertig ist? Gibt es so etwas? Wenn das nicht der Fall ist, könnten wir vielleicht etwas mit Selen machen?

Teilen Sie mir Ihre Gedanken mit. Mir gefällt die Idee, eine Binder-Build-Zuteilung auszulösen, da dies einen Schritt weniger erfordert

Es wäre schön, wenn binderhub eine API hätte, mit der Sie einen Build auslösen und dann einen Link erhalten könnten, wenn er fertig ist? Gibt es so etwas?

Ja tut es. pyhf verwendet dies, um Binder-Builds automatisch auszulösen, wenn wir PRs zusammenführen, sodass unser Start-Binder-Badge immer ein vorgefertigtes Bild für Benutzer hat, aber wenn ich mich richtig an Diskussionen mit @betatim erinnere , wird dies nicht gerade von unterstützt das Binder-Team.

@betatim kannst du mehr darüber sagen, warum das Auslösen solcher Binder-Builds nicht empfohlen wird? Der Grund, warum wir fragen, ist, dass wir versuchen, die Funktionsweise dieser Aktion zu optimieren, und @choldgraf weist darauf hin, dass es für mybinder.org am einfachsten wäre, einen Binderbuild auszulösen, um die API dieser Aktion weiter zu vereinfachen.

Der Grund, warum wir die Leute nicht aktiv dazu ermutigen, ist, dass wir eine Art Ratenbegrenzung implementieren oder „keine alten Revisionen mehr erstellen“ müssten, wenn diese Funktion in großem Umfang verwendet wird. Einzelne Repositories mit gewissenhaften Eigentümern, die beim Zusammenführen mit dem Hauptzweig des Repos automatisch einen Build auslösen, sind in Ordnung. Die ungewaschenen Massen, die bei jedem Commit in jeder PR einen Build auslösen, werden mybinder.org schnell überwältigen (einige Repos benötigen Stunden CPU-Zeit zum Erstellen). .

Ich denke, eine GH-Aktion zu haben, die gut gepflegt ist und das Verhalten implementiert, das für mybinder.org gut ist (automatisches Erstellen beim Zusammenführen mit dem Hauptzweig), ist der richtige Weg. Die Alternative ist, dass immer mehr Leute darauf aufmerksam werden und ihr eigenes Ding umsetzen (in diesem Fall müssen wir einzelne Repos aufspüren).

Für zusätzliche Bonuspunkte wäre es schön, wenn die GH-Aktion auch unsere empfohlene Methode zum Testen, ob Ihre PR "noch auf mybinder.org funktioniert", implementiert, die darin besteht, etwas wie repo2docker . in Ihrem CI zu verwenden, um ein Image lokal zu erstellen . Vielleicht posten Sie einen Link im PR-Kommentar, der einen Binder startet, wenn Sie darauf klicken (er erstellt ihn aber nicht automatisch).

Für zusätzliche Extrapunkte könnten wir den Leuten sogar vorschlagen, wie sie ein Skript im Container ausführen können, um zu überprüfen, ob ihr Code noch läuft (ich verwende so etwas wie repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb ).

Insgesamt ist dies also eine Frage der Rechenressourcen, die auf mybinder.org für die gemeinsame Nutzung verfügbar sind, und der verfügbaren Humanressourcen, um die Ratenbegrenzungs-/Anti-Missbrauchsfunktionen zu erstellen, die wir benötigen würden, wenn dies weit verbreitet ist. Ich möchte, dass dies existiert, und mit ein bisschen Koordination und Zusammenarbeit können wir es meiner Meinung nach schaffen.

Der ursprüngliche „API“-Code: https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

ok, ich denke, das ist definitiv eine handhabbare Sache. Meine Meinung nach dem Feedback:

1. Es klingt so, als wäre es in Ordnung, diese API in dieser Aktion aufzurufen (Menschen könnten sie immer noch missbrauchen, aber ich nehme an, es ist ein prinzipielles Risiko).
2. Der Teil über das Kommentieren der PR mit einem Link zu Binder kann außerhalb dieser Aktion behandelt werden, um die Dinge modular zu halten. Binder macht dies einfach, sodass es einfach wie folgt in Ihren Arbeitsablauf integriert werden kann:

Dieses Beispiel wurde letzte Woche auch im Github-Blog vorgestellt!

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

beiseite: @betatim vielleicht sollte das obige Beispiel in den Binder Docs sein?

1. Ich muss über den zusätzlichen Kredit nachdenken. Das ist interessant, ich denke, ich würde das auch nicht in diese Aktion backen, da dies ein nachgelagerter Schritt sein könnte, nachdem repo2docker ausgeführt wurde.

Bitte lassen Sie mich wissen, wenn Sie Fragen oder Feedback haben. Ich beginne den Prozess des Backens im API-Aufruf, um den mybinder.org-Caching-Prozess zu vereinfachen.

@coldgraf Ich habe das versucht, aber die Benutzererfahrung im Vergleich zum Erstellen des Containers und Übertragen in Ihre eigene Registrierung gefällt mir nicht. Wenn Dinge bei der Verwendung der API fehlschlagen, ist dies nicht so transparent. Außerdem wissen Sie nicht, warum der Build so lange dauert oder warum er hängen bleibt. Ich habe zum Beispiel versucht, es für dieses Repo zu verwenden, und festgestellt, dass die Erstellungszeit tatsächlich ziemlich lang ist (im Vergleich zum Erstellen in Aktionen) - nicht sicher, warum das so ist.

Im Moment habe ich eine Empfehlung in der README-Datei für Leute, Aktionen mit ihrer eigenen Registrierung als Möglichkeit zum Zwischenspeichern einzubauen, aber auch ein Beispiel für das Verschieben auf mybinder.org zu zeigen

Freue mich über Feedback oder weitere Ideen

Hmm - das ist interessant. Könntest du das noch etwas erweitern:

Wenn Dinge bei der Verwendung der API fehlschlagen, ist dies nicht so transparent

Ist das ein Binder-Problem? Etwas, das eine bessere Fehlerprotokollierung erfordert, um es zu verbessern?

Für die Zeit ist das auch eine, bei der ich mir nicht sicher bin. mybinder.org läuft auf der Google Container Registry, die meiner Meinung nach (?) nicht besonders langsamer oder schneller als Dockerhub laufen sollte. Könnte es sein, dass der Dockerhub Layers oder ähnliches zwischengespeichert hat?

Ich denke, dass die Verwendung einer benutzerdefinierten persönlichen Registrierung im Allgemeinen mit Binder nicht ideal ist, da sie auf Personen ausgerichtet ist, die mit Docker nicht vertraut sind, daher denke ich nicht, dass benutzerdefinierte Registrierungen eine großartige langfristige Lösung sind (obwohl ich denke Es gibt bestimmte Forscher, die technisch versierter sind und die es sehr nützlich finden werden!)