Repo2docker-action: Agregue la capacidad de activar un caché *en un binderhub*

Issue-Label Bot aplica automáticamente la etiqueta feature_request a este problema, con una confianza de 0,97. ¡Marque este comentario con :thumbsup: o :thumbsdown: para enviar comentarios a nuestro bot!

Enlaces: página de inicio de la aplicación , tablero y código para este bot.

@chodgraf esta es una excelente idea. "visitar" un enlace no parece algo específico de una acción, solo tenemos que descubrir cómo "visitar" el enlace programáticamente, sería bueno si binderhub tuviera una API mediante la cual pudiera activar una compilación y luego obtener un enlace cuando esté listo? ¿Existe tal cosa? En ausencia de eso, ¿podríamos hacer algún tipo de truco con selenio ?

Déjame saber tu opinión, me gusta la idea de activar una asignación de compilación de carpetas, ya que implica un paso menos

Sería bueno si binderhub tuviera una API mediante la cual pudiera activar una compilación y luego obtener un enlace cuando esté listo. ¿Existe tal cosa?

Sí, lo hace. pyhf usa esto para activar automáticamente compilaciones de Binder cuando fusionamos PR para que nuestra insignia de lanzamiento de Binder siempre tenga una imagen preconstruida para los usuarios, pero si recuerdo correctamente las discusiones con @betatim , esto no está respaldado exactamente por el equipo de Binder.

@betatim , ¿puede ampliar más sobre por qué no se recomienda activar compilaciones de Binder como esta? La razón por la que preguntamos es que estamos tratando de optimizar la forma en que funciona esta Acción, y @chodgraf señala que, para mybinder.org, la forma más fácil sería activar un binderbuild para simplificar aún más la API de esta Acción.

La razón por la que no alentamos activamente a las personas a hacer esto es que tendríamos que implementar algún tipo de limitación de velocidad o "dejar de crear revisiones antiguas" si esta función se usa a escala. Los repositorios individuales con propietarios concienzudos que activan una compilación automáticamente al fusionarse con la rama principal del repositorio están bien, las masas sin lavar que activan una compilación en cada confirmación en cada PR abrumarán rápidamente a mybinder.org (algunos repositorios requieren horas de tiempo de CPU para compilarse) .

Creo que tener una acción de GH que esté bien mantenida e implemente el comportamiento que es bueno para mybinder.org (compilación automática al fusionarse con la rama principal) es el camino a seguir. La alternativa es que más y más personas se den cuenta de esto e implementen sus propias cosas (en cuyo caso tenemos que buscar repositorios individuales).

Para obtener puntos de bonificación adicionales, sería bueno que la acción GH también implementara nuestra forma recomendada de probar si su PR "todavía funciona en mybinder.org", que es usar algo como repo2docker . en su CI para crear una imagen localmente . Tal vez publicar un enlace en el comentario de relaciones públicas que lanzaría un Binder si hiciera clic en él (pero no lo crea automáticamente).

Para obtener crédito adicional, incluso podríamos sugerir a las personas cómo ejecutar un script dentro del contenedor para verificar si su código aún se ejecuta (uso algo como repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb )

Entonces, en general, se trata de recursos informáticos que están disponibles en mybinder.org para que las personas compartan y recursos humanos disponibles para crear las características de limitación de velocidad/anti-abuso que necesitaríamos si esto se generaliza. Quiero que esto exista y con un poco de coordinación y cooperación creo que podemos lograrlo.

El código "API" original: https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

ok, creo que esto es definitivamente una cosa tratable. Mis pensamientos después de escuchar los comentarios:

1. Parece que está bien llamar a esta API en esta Acción (las personas aún podrían abusar de ella, pero supongo que es un riesgo de principio).
2. La parte sobre comentar el PR con un enlace a Binder se puede manejar fuera de esta Acción para mantener las cosas modulares. Binder lo hace fácil, por lo que es fácil de incorporar a su flujo de trabajo de esta manera:

¡Este ejemplo también apareció en el blog de github la semana pasada!

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

aparte: @betatim , ¿quizás el ejemplo anterior debería estar en Binder Docs?

1. Tendré que pensar en el crédito extra. Eso es interesante, creo que tampoco incluiría eso en esta Acción, ya que podría ser un paso posterior después de que se ejecute repo2docker.

Por favor, hágamelo saber si hay alguna pregunta o comentario. Comenzaré el proceso de horneado en la llamada a la API para simplificar el proceso de almacenamiento en caché de mybinder.org.

@chodgraf Probé esto, pero no disfruto de la experiencia del usuario en comparación con la creación del contenedor y la inserción en su propio registro. Cuando las cosas fallan al usar la API, no es tan transparente, además, no sabe por qué la compilación lleva tanto tiempo o qué está causando que se cuelgue. Intenté usarlo para este repositorio, por ejemplo, y descubrí que el tiempo de compilación es bastante largo (en comparación con la compilación en Acciones), no estoy seguro de por qué.

Por ahora, tengo una recomendación sobre el LÉAME para que la gente cree Acciones con su propio registro como una forma de almacenar en caché, pero también muestro un ejemplo de aplazamiento a mybinder.org

Feliz de escuchar cualquier comentario o más ideas

Hmmm - eso es interesante. Podrías ampliar un poco más sobre:

Cuando las cosas fallan al usar la API, no es tan transparente

¿Es un problema de Binder? ¿Algo que necesita un mejor registro de errores para mejorar?

Por el momento, ese también es uno del que no estoy seguro. mybinder.org se ejecuta en el registro de contenedores de Google, que creo (?) No debería ejecutarse particularmente más lento o más rápido que Dockerhub. ¿Podría ser que Dockerhub tuviera capas en caché o algo así?

Creo que, en general, usar un registro personal personalizado no es ideal con Binder, ya que está dirigido a personas que no están familiarizadas con Docker, por lo que no creo que los registros personalizados sean una gran solución a largo plazo (aunque creo que ¡hay ciertos investigadores que tienen más conocimientos técnicos que lo encontrarán muy útil!)