Repo2docker-action: *binderhub*에서 캐시를 트리거하는 기능 추가

Issue-Label Bot은 이 문제에 feature_request 레이블을 0.97의 신뢰도로 자동으로 적용합니다. 봇 피드백을 제공하려면 이 댓글을 :thumbsup: 또는 :thumbsdown:으로 표시하십시오!

링크: 이 봇에 대한 앱 홈페이지 , 대시보드 및 코드 .

@choldgraf 이것은 훌륭한 아이디어입니다. 링크 "방문"은 특정 작업과 같지 않습니다. 프로그래밍 방식으로 링크를 "방문"하는 방법을 알아내야 합니다. 바인더허브에 빌드를 트리거한 다음 링크가 준비되면? 그런 것이 존재합니까? 그것이 없으면 셀레늄 으로 일종의 해킹을 할 수 있습니까?

생각을 알려주세요. 바인더 빌드 할당을 트리거하는 아이디어가 마음에 듭니다. 한 단계 덜 필요하기 때문입니다.

바인더허브에 빌드를 트리거한 다음 준비가 되면 링크를 얻을 수 있는 API가 있다면 좋을 것입니다. 그런 것이 존재합니까?

네, 그렇습니다. pyhf 는 이를 사용하여 PR을 병합할 때 Binder 빌드를 자동으로 트리거하여 출시 Binder 배지가 항상 사용자를 위해 미리 빌드된 이미지를 갖도록 하지만 @betatim 과의 토론이 올바르게 기억난다면 이것은 다음에서 정확히 보증하지 않습니다. 바인더 팀.

@betatim 이와 같이 바인더 빌드를 트리거하는 것이 권장되지 않는 이유에 대해 더 자세히 설명할 수 있습니까? 우리가 묻는 이유는 우리가 이 액션이 작동하는 방식을 최적화하려고 하기 때문이며 @choldgraf 는 mybinder.org의 경우 가장 쉬운 방법은 이 액션의 API를 더욱 단순화하기 위해 바인더 빌드를 트리거하는 것이라고 지적했습니다.

사람들이 이 작업을 수행하도록 적극적으로 권장하지 않는 이유는 이 기능을 대규모로 사용하는 경우 속도 제한의 일부 형태를 구현하거나 "이전 버전 빌드를 중지"해야 하기 때문입니다. 리포지토리의 주요 분기에 병합할 때 자동으로 빌드를 트리거하는 성실한 소유자가 있는 개별 리포지토리는 괜찮습니다. 모든 PR의 모든 커밋에서 빌드를 트리거하는 세척되지 않은 대중은 mybinder.org를 빠르게 압도할 것입니다(일부 리포지토리는 빌드하는 데 CPU 시간이 몇 시간 걸립니다). .

잘 유지 관리되고 mybinder.org(메인 브랜치에 병합 시 자동 빌드)에 좋은 동작을 구현하는 하나의 GH 작업을 갖는 것이 갈 길이라고 생각합니다. 대안은 점점 더 많은 사람들이 이에 대해 현명해지고 자신의 것을 구현하는 것입니다(이 경우 개별 저장소를 추적해야 함).

추가 보너스 포인트를 얻으려면 GH 조치가 PR이 "mybinder.org에서 여전히 작동"하는 경우 권장되는 테스트 방법도 구현하면 좋을 것입니다. 이는 CI에서 repo2docker . 와 같은 것을 사용하여 로컬에서 이미지를 빌드하는 것입니다. . 클릭하면 바인더를 실행하는 링크를 PR 댓글에 게시할 수도 있습니다(자동 빌드는 아님).

추가 크레딧을 위해 우리는 사람들에게 컨테이너 내부에서 스크립트를 실행하여 코드가 여전히 실행되는지 확인하는 방법을 제안할 수도 있습니다(저는 repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb 와 같은 것을 사용합니다).

따라서 전반적으로 이것은 사람들이 공유할 수 있도록 mybinder.org에서 사용할 수 있는 컴퓨팅 리소스와 이것이 널리 퍼질 경우 필요한 속도 제한/남용 방지 기능을 구축하는 데 사용할 수 있는 인적 리소스의 문제입니다. 나는 이것이 존재하기를 원하고 약간의 조정과 협력으로 그것을 해낼 수 있다고 생각합니다.

원래 "API" 코드: https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

좋아 이것은 확실히 다루기 쉬운 일이라고 생각합니다. 피드백을 들은 후의 생각:

1. 이 작업에서 이 API를 호출하는 것이 괜찮은 것 같습니다(사람들이 여전히 이를 남용할 수 있지만 원칙적 위험이라고 생각합니다).
2. Binder에 대한 링크가 있는 PR에 대한 주석 처리에 대한 부분은 모듈을 유지하기 위해 이 Action 외부에서 처리할 수 있습니다. 바인더를 사용하면 이를 쉽게 수행할 수 있으므로 다음과 같이 워크플로에 쉽게 통합할 수 있습니다.

이 예제는 지난주 github 블로그에도 소개되었습니다!

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

제쳐두고: @betatim 아마도 위의 예가 바인더 문서에 있어야 합니까?

1. 추가 크레딧에 대해 생각해야 합니다. 흥미롭네요. repo2docker가 실행된 후 다운스트림 단계가 될 수 있으므로 이 작업에 적용하지 않을 것입니다.

질문이나 피드백이 있으면 알려주세요. mybinder.org 캐싱 프로세스를 단순화하기 위해 API 호출에서 베이킹 프로세스를 시작하겠습니다.

@choldgraf 나는 이것을 시도했지만 컨테이너를 구축하고 자신의 레지스트리에 푸시하는 것과 비교하여 사용자 경험을 즐기지 않습니다. API를 사용할 때 일이 실패하면 투명하지 않고 빌드에 시간이 오래 걸리는 이유나 빌드가 중단되는 원인을 알 수 없습니다. 예를 들어 이 리포지토리에 사용하려고 시도한 결과 빌드 시간이 실제로 상당히 길다는 것을 알았습니다(액션에서 빌드하는 것과 비교하여) -- 왜 그런지는 모르겠습니다.

지금 당장은 캐시를 위한 방법으로 자신의 레지스트리를 사용하여 Actions에서 빌드하는 사람들을 위한 README에 대한 권장 사항이 있지만 mybinder.org로 연기하는 예도 보여줍니다.

피드백이나 더 많은 아이디어를 듣게 되어 기쁩니다.

흠 - 흥미롭네요. 다음에 대해 좀 더 확장할 수 있습니까?

API를 사용할 때 일이 실패하면 투명하지 않습니다.

바인더 문제인가요? 개선하기 위해 더 나은 오류 로깅이 필요한 것이 있습니까?

당분간은 저도 잘 모르겠습니다. mybinder.org는 Google 컨테이너 레지스트리에서 실행되며(?) Dockerhub보다 특히 느리거나 빨라서는 안 된다고 생각합니다. Dockerhub에 캐시된 레이어 또는 이와 유사한 것이 있을 수 있습니까?

일반적으로 사용자 지정 개인 레지스트리를 사용하는 것은 Docker에 익숙하지 않은 사람들을 대상으로 하기 때문에 바인더에 이상적이지 않다고 생각합니다. 따라서 사용자 지정 레지스트리가 훌륭한 장기적 솔루션이라고 생각하지 않습니다(내 생각에는 기술적으로 더 잘 알고 있는 특정 연구원이 있어 매우 유용할 것입니다!)