Repo2docker-action: Ajouter la possibilité de déclencher un cache *sur un binderhub*

Issue-Label Bot applique automatiquement l'étiquette feature_request à ce problème, avec une confiance de 0,97. Veuillez marquer ce commentaire avec :thumbsup: ou :thumbsdown: pour faire part de vos commentaires à notre bot !

Liens : page d'accueil de l'application , tableau de bord et code pour ce bot.

@choldgraf c'est une excellente idée. "visiter" un lien ne semble pas être quelque chose de spécifique à une action, nous devons juste comprendre comment "visiter" le lien par programme, ce serait bien si binderhub avait une API par laquelle vous pourriez déclencher une construction et ensuite obtenir un lien quand c'est prêt? Est-ce qu'une telle chose existe? En l'absence de cela, nous pourrions peut-être faire une sorte de truc hacky avec du sélénium ?

Faites-moi part de vos réflexions, j'aime l'idée de déclencher une allocation de construction de classeur car cela implique une étape de moins

ce serait bien si binderhub disposait d'une API permettant de déclencher une construction, puis d'obtenir un lien lorsqu'il est prêt ? Est-ce qu'une telle chose existe?

Oui. pyhf l'utilise pour déclencher automatiquement les versions de Binder lorsque nous fusionnons les PR afin que notre badge de lancement Binder ait toujours une image pré-construite pour les utilisateurs, mais si je me souviens correctement des discussions avec @betatim , ce n'est pas exactement approuvé par l'équipe Binder.

@betatim pouvez-vous expliquer pourquoi le déclenchement de versions de Binder comme celle-ci n'est pas encouragé ? La raison pour laquelle nous demandons est que nous essayons d'optimiser le fonctionnement de cette action, et @choldgraf souligne que pour mybinder.org, le moyen le plus simple serait de déclencher un binderbuild pour simplifier davantage l'API de cette action.

La raison pour laquelle nous n'encourageons pas activement les gens à le faire est que nous devrions implémenter une forme de limitation de débit ou "arrêter de créer d'anciennes révisions" si cette fonctionnalité est utilisée à grande échelle. Les référentiels individuels avec des propriétaires consciencieux qui déclenchent automatiquement une construction lors de la fusion dans la branche principale du dépôt, c'est bien, les masses non lavées déclenchant une construction sur chaque commit dans chaque PR submergeront rapidement mybinder.org (certains dépôts prennent des heures de temps CPU à construire) .

Je pense qu'avoir une action GH qui est bien entretenue et implémente le comportement qui est bon pour mybinder.org (construction automatique lors de la fusion avec la branche principale) est la voie à suivre. L'alternative est que de plus en plus de gens deviennent conscients de cela et implémentent leur propre chose (auquel cas nous devons rechercher des dépôts individuels).

Pour des points bonus supplémentaires, ce serait bien si l'action GH implémentait également notre méthode recommandée pour tester si votre PR "fonctionne toujours sur mybinder.org", qui consiste à utiliser quelque chose comme repo2docker . dans votre CI pour créer une image localement . Peut-être publier un lien dans le commentaire PR qui lancerait un classeur si vous cliquiez dessus (mais ne le construit pas automatiquement).

Pour un crédit supplémentaire supplémentaire, nous pourrions même suggérer aux gens comment exécuter un script à l'intérieur du conteneur pour vérifier si leur code fonctionne toujours (j'utilise quelque chose comme repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb )

Donc, dans l'ensemble, il s'agit de ressources de calcul disponibles sur mybinder.org pour que les gens puissent les partager et de ressources humaines disponibles pour créer les fonctionnalités de limitation de débit/anti-abus dont nous aurions besoin si cela se généralisait. Je veux que cela existe et avec un peu de coordination et de coopération, je pense que nous pouvons y arriver.

Le code "API" d'origine : https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

ok je pense que c'est définitivement une chose traitable. Mon avis après avoir entendu les commentaires :

1. Il semble que ce soit correct d'appeler cette API dans cette action (les gens pourraient toujours en abuser, mais je suppose que c'est un risque de principe).
2. La partie concernant les commentaires sur le PR avec un lien vers Binder peut être gérée en dehors de cette action pour garder les choses modulaires. Binder rend cela facile, il est donc facile à intégrer dans votre flux de travail comme ceci :

Cet exemple a également été présenté dans le blog github la semaine dernière !

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

de côté : @betatim peut-être que l'exemple ci-dessus devrait être dans la documentation Binder ?

1. Je vais devoir penser au crédit supplémentaire. C'est intéressant, je pense que je ne ferais pas non plus cela dans cette action car cela pourrait être une étape en aval après l'exécution de repo2docker.

S'il vous plaît laissez-moi savoir s'il y a des questions ou des commentaires. Je vais commencer le processus de cuisson dans l'appel API pour simplifier le processus de mise en cache mybinder.org.

@choldgraf J'ai essayé cela mais je n'apprécie pas l'expérience utilisateur par rapport à la construction du conteneur et à sa diffusion dans votre propre registre. Lorsque les choses échouent lors de l'utilisation de l'API, ce n'est pas aussi transparent, vous ne savez pas non plus pourquoi la construction prend beaucoup de temps ou ce qui la fait se bloquer. J'ai essayé de l'utiliser pour ce référentiel, par exemple, et j'ai constaté que le temps de construction est en fait assez long (par rapport à la construction dans Actions) - je ne sais pas pourquoi.

Pour le moment, j'ai une recommandation sur le README pour que les gens intègrent des actions avec leur propre registre comme moyen de mise en cache, mais montrent également un exemple de report à mybinder.org

Heureux d'entendre des commentaires ou plus d'idées

Hmmm - c'est intéressant. Pourriez-vous développer un peu plus sur :

Lorsque les choses échouent lors de l'utilisation de l'API, ce n'est pas aussi transparent

Est-ce un problème de classeur ? Quelque chose qui nécessite une meilleure journalisation des erreurs pour s'améliorer ?

Pour le moment, c'est aussi celui dont je ne suis pas sûr. mybinder.org s'exécute sur le registre de conteneurs de Google, qui, à mon avis (?) ne devrait pas être particulièrement lent ou plus rapide que Dockerhub. Se pourrait-il que le Dockerhub ait des couches en cache ou quelque chose comme ça ?

Je pense qu'en général, l'utilisation d'un registre personnel personnalisé n'est pas idéale avec Binder car il est destiné aux personnes qui ne connaissent pas Docker, donc je ne pense pas que les registres personnalisés soient une excellente solution à long terme (bien que je pense il y a certains chercheurs plus avertis techniquement qui le trouveront très utile !)