Repo2docker-action: أضف القدرة على تشغيل ذاكرة التخزين المؤقت * على Binderhub *

يقوم برنامج Issue-Label Bot تلقائيًا بتطبيق التصنيف feature_request لهذه المشكلة بثقة تبلغ 0.97. يرجى وضع علامة على هذا التعليق بـ: thumbsup: أو: thumbs down: لإعطاء ملاحظات bot الخاصة بنا!

الروابط: الصفحة الرئيسية للتطبيق ولوحة القيادة والرمز لهذا الروبوت.

choldgraf هذه فكرة ممتازة. لا يبدو أن "زيارة" الرابط شيئًا محددًا لإجراء ما ، علينا فقط معرفة كيفية "زيارة" الرابط برمجيًا ، وسيكون من الجيد أن يكون لدى Binderhub واجهة برمجة تطبيقات يمكنك بواسطتها تشغيل بناء ثم الحصول على الارتباط عندما يكون جاهزا؟ هل يوجد شيء من هذا القبيل؟ في حالة عدم وجود ذلك ، قد نكون قادرين على القيام بشيء من الاختراق باستخدام السيلينيوم ؟

اسمحوا لي أن أعرف أفكاركم ، أحب فكرة تشغيل تخصيص بناء الموثق لأنه يتضمن خطوة واحدة أقل

سيكون من الرائع لو كان لدى Binderhub واجهة برمجة تطبيقات يمكنك بواسطتها تشغيل بناء ثم الحصول على رابط عندما يكون جاهزًا؟ هل يوجد شيء من هذا القبيل؟

نعم إنها كذلك. يستخدم pyhf هذا لتشغيل إصدارات Binder تلقائيًا عندما ندمج العلاقات العامة بحيث تحتوي شارة إطلاق Binder الخاصة بنا دائمًا على صورة مسبقة الصنع للمستخدمين ، ولكن إذا كنت أتذكر المناقشات مع betatim بشكل صحيح ، فهذا ليس معتمدًا تمامًا من قبل فريق Binder.

betatim هل يمكنك توسيع المزيد حول سبب عدم تشجيع تشغيل إنشاءات Binder مثل هذه؟ السبب وراء طلبنا هو أننا نحاول تحسين طريقة عمل هذا الإجراء ، ويشير choldgraf إلى أن أسهل طريقة بالنسبة لموقع mybinder.org هي تشغيل binderbuild لزيادة تبسيط واجهة برمجة التطبيقات لهذا الإجراء.

السبب في أننا لا نشجع الأشخاص بنشاط على القيام بذلك هو أنه يتعين علينا تنفيذ شكل من أشكال تحديد المعدل أو "التوقف عن إنشاء المراجعات القديمة" إذا تم استخدام هذه الميزة على نطاق واسع. المستودعات الفردية مع أصحاب الضمير الذين يقومون بتشغيل البناء تلقائيًا عند الدمج في الفرع الرئيسي من الريبو أمر جيد ، فالكتل غير المغسولة التي تؤدي إلى بناء على كل التزام في كل علاقات عامة سوف تطغى بسرعة على mybinder.org (بعض مستودعات إعادة الشراء تستغرق ساعات من وقت وحدة المعالجة المركزية للبناء) .

أعتقد أن وجود إجراء GH واحد يتم صيانته جيدًا وينفذ السلوك الجيد لـ mybinder.org (الإنشاء التلقائي عند الدمج مع الفرع الرئيسي) هو السبيل للذهاب. البديل هو أن المزيد والمزيد من الناس يصبحون حكماء في هذا الأمر وينفذون شيئًا خاصًا بهم (في هذه الحالة ، يتعين علينا تتبع عمليات إعادة الشراء الفردية).

بالنسبة إلى نقاط المكافآت الإضافية ، سيكون من الجيد إذا نفذ إجراء GH أيضًا طريقتنا الموصى بها للاختبار إذا كانت العلاقات العامة الخاصة بك "لا تزال تعمل على mybinder.org" والتي تتمثل في استخدام شيء مثل repo2docker . في CI الخاص بك لبناء صورة محليًا . ربما يتم نشر رابط في تعليق العلاقات العامة من شأنه تشغيل Binder إذا قمت بالنقر فوقه (ولكن لا يقوم بإنشائه تلقائيًا).

للحصول على رصيد إضافي ، يمكننا حتى اقتراح كيفية تشغيل برنامج نصي داخل الحاوية لمعرفة ما إذا كانت التعليمات البرمجية الخاصة بهم لا تزال تعمل (أستخدم شيئًا مثل repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb )

إذن بشكل عام ، هذه مسألة موارد حسابية متاحة على mybinder.org ليشاركها الأشخاص والموارد البشرية المتاحة لبناء ميزات الحد من / مكافحة إساءة الاستخدام التي سنحتاجها إذا أصبح هذا منتشرًا على نطاق واسع. أريد أن يكون هذا موجودًا وبقليل من التنسيق والتعاون أعتقد أنه يمكننا تحقيق ذلك.

كود "API" الأصلي: https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

حسنًا ، أعتقد أن هذا بالتأكيد شيء يمكن تتبعه. أفكاري بعد سماع الملاحظات:

1. يبدو أنه من الجيد استدعاء واجهة برمجة التطبيقات هذه في هذا الإجراء (لا يزال بإمكان الأشخاص إساءة استخدامها ، لكنني أفترض أنها مخاطرة مبدئية).
2. يمكن التعامل مع الجزء المتعلق بالتعليق على العلاقات العامة مع ارتباط إلى Binder خارج هذا الإجراء لإبقاء الأشياء معيارية. يجعل Binder هذا الأمر سهلاً ، لذلك من السهل دمجه في سير عملك على النحو التالي:

ظهر هذا المثال أيضًا في مدونة جيثب الأسبوع الماضي!

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 لقد جربت هذا ولكن لا تستمتع بتجربة المستخدم مقارنةً ببناء الحاوية ودفعها إلى السجل الخاص بك. عندما تفشل الأشياء عند استخدام واجهة برمجة التطبيقات ، فإنها لا تكون شفافة بنفس القدر ، كما أنك لا تعرف سبب استغراق الإنشاء وقتًا طويلاً أو سبب تعطله. حاولت استخدامه لهذا الريبو ، على سبيل المثال ووجدت أن وقت الإنشاء طويل جدًا في الواقع (مقارنة بالبناء في الإجراءات) - لست متأكدًا من سبب ذلك.

في الوقت الحالي ، لديّ توصية بشأن README للأشخاص لبناء إجراءات باستخدام السجل الخاص بهم كطريقة للتخزين المؤقت ، ولكن أيضًا أظهر مثالاً للتأجيل إلى mybinder.org

سعيد لسماع أي ردود فعل أو المزيد من الأفكار

هممم - هذا مثير للاهتمام. هل يمكنك التوسع قليلاً في:

عندما تفشل الأشياء عند استخدام API ، فإنها لا تكون شفافة

هل هذه قضية بيندر؟ شيء يحتاج إلى تسجيل خطأ أفضل لتحسينه؟

في الوقت الحالي ، هذا أيضًا أمر لست متأكدًا منه. يعمل mybinder.org على سجل حاوية google ، والذي أعتقد أنه (؟) لا ينبغي أن يعمل بشكل أبطأ أو أسرع من Dockerhub. هل يمكن أن يكون Dockerhub يحتوي على طبقات مخبأة أو شيء من هذا القبيل؟

أعتقد أن استخدام سجل شخصي مخصص بشكل عام ليس مثاليًا مع Binder لأنه موجه للأشخاص الذين ليسوا على دراية بـ Docker ، لذلك لا أعتقد أن السجلات المخصصة هي حل رائع طويل الأجل (على الرغم من أنني أعتقد هناك بعض الباحثين الأكثر ذكاءً من الناحية التقنية ويجدونها مفيدة جدًا!)