Repo2docker-action: Добавить возможность активировать кеш *на связующем хабе*

Бот Issue-Label автоматически присваивает этой проблеме метку feature_request с достоверностью 0,97. Отметьте этот комментарий знаком :thumbsup: или :thumbsdown:, чтобы оставить отзыв о нашем боте!

Ссылки: домашняя страница приложения , панель инструментов и код этого бота.

@choldgraf это отличная идея. «посещение» ссылки не похоже на что-то конкретное для действия, нам просто нужно выяснить, как «посетить» ссылку программно, было бы неплохо, если бы у binderhub был API, с помощью которого вы могли бы запустить сборку, а затем получить ссылку когда будет готово? Существует ли такая вещь? В отсутствие этого мы могли бы сделать что-то хакерское с селеном ?

Дайте мне знать ваши мысли, мне нравится идея запуска выделения сборки связующего, так как это требует на один шаг меньше

было бы неплохо, если бы у binderhub был API, с помощью которого вы могли бы запустить сборку, а затем получить ссылку, когда она будет готова? Существует ли такая вещь?

Да. pyhf использует это для автоматического запуска сборок Binder при объединении PR, чтобы у нашего значка запуска Binder всегда было предварительно созданное изображение для пользователей, но, если я правильно помню обсуждения с @betatim , это не совсем одобрено команда Биндера.

@betatim , можете ли вы подробнее рассказать о том, почему запуск подобных сборок Binder не рекомендуется? Причина, по которой мы спрашиваем, заключается в том, что мы пытаемся оптимизировать работу этого действия, и @choldgraf указывает, что для mybinder.org самым простым способом было бы запустить сборку привязки для дальнейшего упрощения API этого действия.

Причина, по которой мы активно не поощряем людей делать это, заключается в том, что нам пришлось бы реализовать некоторую форму ограничения скорости или «прекратить создавать старые версии», если эта функция используется в масштабе. Отдельные репозитории с добросовестными владельцами, которые автоматически запускают сборку при слиянии с основной веткой репо, — это нормально, немытые массы, запускающие сборку при каждом коммите в каждом PR, быстро перегрузят mybinder.org (некоторые репозитории требуют часов процессорного времени для сборки). .

Я думаю, что иметь одно действие GH, которое хорошо поддерживается и реализует поведение, подходящее для mybinder.org (автоматическая сборка при слиянии с основной веткой), — это путь. Альтернативой является то, что все больше и больше людей понимают это и реализуют свои собственные вещи (в этом случае нам нужно отслеживать отдельные репозитории).

Для дополнительных бонусных баллов было бы неплохо, если бы действие GH также реализовало рекомендуемый нами способ тестирования, если ваш PR «все еще работает на mybinder.org», то есть использовать что-то вроде repo2docker . в вашем CI для локального создания образа. . Может быть, опубликовать ссылку в PR-комментарии, которая запустит Binder, если вы щелкнете по ней (но не создаст ее автоматически).

Для дополнительной дополнительной оценки мы могли бы даже предложить людям, как запустить скрипт внутри контейнера, чтобы проверить, работает ли их код (я использую что-то вроде repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb )

Таким образом, в целом это вопрос вычислительных ресурсов, доступных на mybinder.org для обмена людьми, и человеческих ресурсов, доступных для создания функций ограничения скорости / защиты от злоупотреблений, которые нам понадобятся, если это станет широко распространенным. Я хочу, чтобы это существовало, и я думаю, что с небольшой координацией и сотрудничеством мы сможем это осуществить.

Исходный код API: https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py .

хорошо, я думаю, что это определенно поддающаяся обработке вещь. Мои мысли после отзыва:

1. Похоже, можно вызывать этот API в этом действии (люди могут злоупотреблять им, но я полагаю, что это принципиальный риск).
2. Часть о комментировании PR со ссылкой на Binder может быть обработана вне этого действия, чтобы сохранить модульность. Binder упрощает это, поэтому его легко включить в рабочий процесс следующим образом:

Этот пример также был представлен в блоге 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 , возможно, приведенный выше пример должен быть в Binder Docs?

1. Мне придется подумать о дополнительном кредите. Это интересно, я думаю, что я бы также не включил это в это действие, поскольку это может быть последующим шагом после запуска repo2docker.

Пожалуйста, дайте мне знать, если есть какие-либо вопросы или отзывы. Я начну процесс запекания в вызове API, чтобы упростить процесс кэширования mybinder.org.

@choldgraf Я пробовал это, но мне не нравится пользовательский интерфейс по сравнению с созданием контейнера и его отправкой в ​​​​ваш собственный реестр. Когда что-то терпит неудачу при использовании API, это не так прозрачно, и вы также не знаете, почему сборка занимает много времени или что вызывает ее зависание. Например, я попытался использовать его для этого репозитория и обнаружил, что время сборки на самом деле довольно велико (по сравнению со сборкой в ​​Actions) — не уверен, почему это так.

На данный момент у меня есть рекомендация в README для людей, чтобы встроить действия с их собственным реестром в качестве способа кэширования, а также показать пример откладывания на mybinder.org

Рад услышать любую обратную связь или больше идей

Мммм - это интересно. Не могли бы вы немного подробнее остановиться на:

Когда что-то терпит неудачу при использовании API, это не так прозрачно

Это проблема Биндера? Что-то, что требует улучшения регистрации ошибок?

На данный момент это тоже то, в чем я не уверен. mybinder.org работает в реестре контейнеров Google, который, я думаю (?), не должен работать особенно медленнее или быстрее, чем Dockerhub. Может быть, в Dockerhub были кешированные слои или что-то в этом роде?

Я действительно думаю, что в целом использование пользовательского личного реестра не идеально для Binder, поскольку он ориентирован на людей, незнакомых с Docker, поэтому я не думаю, что пользовательские реестры — отличное долгосрочное решение (хотя я думаю есть некоторые исследователи, более технически подкованные, которые сочтут это очень полезным!)