Repo2docker-action: Adicione a capacidade de acionar um cache *em um binderhub*

O Issue-Label Bot está aplicando automaticamente o rótulo feature_request a este problema, com uma confiança de 0,97. Por favor, marque este comentário com :thumbsup: ou :thumbsdown: para dar feedback ao nosso bot!

Links: página inicial do aplicativo , painel e código para este bot.

@choldgraf esta é uma excelente ideia. "visitar" um link não parece algo específico para uma ação, só temos que descobrir como "visitar" o link programaticamente, seria bom se o binderhub tivesse uma API pela qual você pudesse acionar uma compilação e obter um link quando estiver pronto? Será que tal coisa existe? Na ausência disso, talvez possamos fazer algum tipo de coisa hacky com selênio ?

Deixe-me saber seus pensamentos, eu gosto da ideia de acionar um lote de criação de fichário, pois envolve uma etapa a menos

seria bom se o binderhub tivesse uma API pela qual você pudesse acionar uma compilação e obter um link quando estiver pronto? Será que tal coisa existe?

Sim. pyhf usa isso para acionar automaticamente compilações do Binder quando mesclamos PRs para que nosso selo de lançamento do Binder sempre tenha uma imagem pré-criada para os usuários, mas se me lembro corretamente das discussões com @betatim , isso não é exatamente endossado por a equipe do Binder.

@betatim você pode expandir mais sobre por que o acionamento de compilações do Binder como essa não é incentivado? A razão pela qual estamos perguntando é que estamos tentando otimizar a maneira como essa ação funciona, e @chodgraf aponta que para mybinder.org a maneira mais fácil seria acionar um binderbuild para simplificar ainda mais a API dessa ação.

A razão pela qual não incentivamos ativamente as pessoas a fazer isso é que teríamos que implementar alguma forma de limitação de taxa ou "parar de criar revisões antigas" se esse recurso fosse usado em escala. Repositórios individuais com proprietários conscientes que acionam uma compilação automaticamente na mesclagem na ramificação principal do repositório é bom, as massas não lavadas que acionam uma compilação em cada confirmação em cada PR sobrecarregarão rapidamente o mybinder.org (alguns repositórios levam horas de tempo de CPU para serem compilados) .

Eu acho que ter uma ação GH que é bem mantida e implementa o comportamento que é bom para mybinder.org (auto build on merge to main branch) é o caminho a seguir. A alternativa é que mais e mais pessoas se conscientizem disso e implementem suas próprias coisas (nesse caso, temos que rastrear repos individuais).

Para pontos de bônus extra, seria bom se a ação do GH também implementasse nossa maneira recomendada de testar se seu PR "ainda funciona em mybinder.org", que é usar algo como repo2docker . em seu CI para criar uma imagem localmente . Talvez postar um link no comentário do PR que lançaria um Binder se você clicasse nele (mas não o construísse automaticamente).

Para crédito extra extra, poderíamos até sugerir às pessoas como executar um script dentro do contêiner para verificar se o código ainda é executado (eu uso algo como repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb )

Então, no geral, esta é uma questão de recursos de computação que estão disponíveis no mybinder.org para as pessoas compartilharem e recursos humanos disponíveis para construir os recursos de limitação de taxa/anti-abuso que precisaríamos se isso se espalhar. Eu quero que isso exista e com um pouco de coordenação e cooperação acho que podemos conseguir.

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

ok, eu acho que isso é definitivamente uma coisa tratável. Meus pensamentos depois de ouvir o feedback:

1. Parece que não há problema em chamar essa API nesta ação (as pessoas ainda podem abusar dela, mas suponho que seja um risco de princípios).
2. A parte sobre comentar o PR com um link para o Binder pode ser tratada fora desta Ação para manter as coisas modulares. O Binder facilita isso, por isso é fácil incorporá-lo ao seu fluxo de trabalho assim:

Este exemplo também foi apresentado no blog do github na semana passada!

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

à parte: @betatim talvez o exemplo acima deva estar no Binder Docs?

1. Vou ter que pensar no crédito extra. Isso é interessante, acho que também não colocaria isso nessa ação, pois isso poderia ser uma etapa posterior após a execução do repo2docker.

Por favor, deixe-me saber se houver alguma dúvida ou feedback. Iniciarei o processo de preparação na chamada da API para simplificar o processo de armazenamento em cache do mybinder.org.

@cholgraf Eu tentei isso, mas não aproveito a experiência do usuário em comparação com a construção do contêiner e o envio para seu próprio registro. Quando as coisas falham ao usar a API, não é tão transparente, também você não sabe por que a compilação está demorando muito ou o que está causando o travamento. Eu tentei usá-lo para este repositório, por exemplo, e descobri que o tempo de compilação é realmente muito longo (em comparação com a compilação em Ações) - não sei por que isso acontece.

Por enquanto, tenho uma recomendação no README para que as pessoas construam em Actions com seu próprio registro como forma de cache, mas também mostro um exemplo de adiamento para mybinder.org

Feliz em ouvir qualquer feedback ou mais ideias

Hmmm - isso é interessante. Você poderia expandir um pouco mais sobre:

Quando as coisas falham ao usar a API, não é tão transparente

Isso é um problema do Binder? Algo que precisa de um melhor registro de erros para melhorar?

Por enquanto, isso também é algo sobre o qual não tenho certeza. mybinder.org é executado no registro de contêiner do google, que eu acho (?) não deve ser executado particularmente mais lento ou mais rápido que o Dockerhub. Será que o Dockerhub tinha camadas em cache ou algo assim?

Eu acho que, em geral, usar um registro pessoal personalizado não é ideal com o Binder, pois é voltado para pessoas que não estão familiarizadas com o Docker, então não acho que os registros personalizados sejam uma ótima solução de longo prazo (embora eu ache que há certos pesquisadores que são mais experientes tecnicamente que acharão muito útil!)