Repo2docker-action: कैश को ट्रिगर करने की क्षमता जोड़ें * एक बाइंडरहब पर *

इश्यू-लेबल बॉट 0.97 के भरोसे के साथ इस मुद्दे पर स्वचालित रूप से feature_request लेबल लागू कर रहा है। हमारे बॉट फ़ीडबैक देने के लिए कृपया इस टिप्पणी को :thumbsup: या :thumbsdown: से चिह्नित करें!

लिंक: इस बॉट के लिए ऐप होमपेज , डैशबोर्ड और कोड ।

@choldgraf यह एक उत्कृष्ट विचार है। किसी लिंक को "विज़िट" करना किसी क्रिया के लिए कुछ विशिष्ट नहीं लगता है, हमें बस यह पता लगाना है कि लिंक को प्रोग्रामेटिक रूप से "विज़िट" कैसे करें, यह अच्छा होगा यदि बाइंडरहब में एक एपीआई हो जिससे आप एक बिल्ड को ट्रिगर कर सकें और फिर प्राप्त कर सकें लिंक कब तैयार है? क्या ऐसी किसी वस्तु का अस्तित्व है? उसके अभाव में, हम सेलेनियम के साथ किसी प्रकार की हैकी चीज करने में सक्षम हो सकते हैं?

मुझे अपने विचार बताएं, मुझे बाइंडर बिल्ड आवंटन को ट्रिगर करने का विचार पसंद है क्योंकि इसमें एक कम चरण शामिल है

यह अच्छा होगा यदि बाइंडरहब के पास एक एपीआई है जिससे आप एक बिल्ड को ट्रिगर कर सकते हैं और उसके तैयार होने पर एक लिंक प्राप्त कर सकते हैं? क्या ऐसी किसी वस्तु का अस्तित्व है?

हाँ ऐसा होता है। pyhf इसका उपयोग स्वचालित रूप से बाइंडर बिल्ड को ट्रिगर करने के लिए करता है जब हम पीआर को मर्ज करते हैं ताकि हमारे लॉन्च बाइंडर बैज में हमेशा उपयोगकर्ताओं के लिए एक पूर्व-निर्मित छवि हो, लेकिन अगर मुझे @betatim के साथ चर्चा सही ढंग से याद है, तो इसका बिल्कुल समर्थन नहीं है बाइंडर टीम।

@betatim क्या आप इस बारे में अधिक विस्तार कर सकते हैं कि बाइंडर को इस तरह से ट्रिगर करने के लिए प्रोत्साहित क्यों नहीं किया जाता है? हम जो कारण पूछ रहे हैं वह यह है कि हम इस क्रिया के काम करने के तरीके को अनुकूलित करने की कोशिश कर रहे हैं, और @choldgraf बताते हैं कि mybinder.org के लिए सबसे आसान तरीका इस क्रिया के एपीआई को और सरल बनाने के लिए एक बाइंडरबिल्ड को ट्रिगर करना होगा।

इसका कारण यह है कि हम लोगों को ऐसा करने के लिए सक्रिय रूप से प्रोत्साहित नहीं करते हैं कि अगर इस सुविधा का बड़े पैमाने पर उपयोग किया जाता है तो हमें दर सीमित करने के किसी न किसी रूप को लागू करना होगा या "पुराने संशोधन बनाना बंद करना होगा"। ईमानदार मालिकों के साथ व्यक्तिगत भंडार जो रेपो की मुख्य शाखा में विलय पर स्वचालित रूप से एक निर्माण को ट्रिगर करते हैं, ठीक है, प्रत्येक पीआर में प्रत्येक प्रतिबद्धता पर निर्माण को ट्रिगर करने वाले अनचाहे लोग जल्दी से mybinder.org को अभिभूत कर देंगे (कुछ रेपो बनाने के लिए सीपीयू समय के घंटे लगते हैं) .

मुझे लगता है कि एक जीएच क्रिया जो अच्छी तरह से बनाए रखी जाती है और उस व्यवहार को लागू करती है जो mybinder.org के लिए अच्छा है (मुख्य शाखा में विलय पर ऑटो निर्माण) जाने का रास्ता है। विकल्प यह है कि अधिक से अधिक लोग इसके प्रति समझदार हों और अपनी बात को लागू करें (जिस स्थिति में हमें व्यक्तिगत रेपो को ट्रैक करना होगा)।

अतिरिक्त बोनस अंक के लिए यह अच्छा होगा यदि जीएच कार्रवाई ने परीक्षण के हमारे अनुशंसित तरीके को भी लागू किया है यदि आपका पीआर "अभी भी mybinder.org पर काम करता है" जो कि स्थानीय रूप से एक छवि बनाने के लिए आपके सीआई में repo2docker . जैसे कुछ का उपयोग करना है। . हो सकता है कि पीआर टिप्पणी में एक लिंक पोस्ट करना जो एक बाइंडर लॉन्च करेगा यदि आप इसे क्लिक करते हैं (लेकिन इसे ऑटो नहीं बनाते हैं)।

अतिरिक्त अतिरिक्त क्रेडिट के लिए हम लोगों को यह भी सुझाव दे सकते हैं कि कंटेनर के अंदर एक स्क्रिप्ट कैसे चलाएं ताकि यह जांचा जा सके कि उनका कोड अभी भी चलता है (मैं repo2docker . -- jupyter-nbconvert --execute some/notebook.ipynb जैसे कुछ का उपयोग करता हूं)

तो कुल मिलाकर यह उन कंप्यूट संसाधनों का सवाल है जो लोगों को साझा करने के लिए mybinder.org पर उपलब्ध हैं और यदि यह व्यापक प्रसार हो जाता है तो हमें दर सीमित/दुरुपयोग-विरोधी सुविधाओं के निर्माण के लिए उपलब्ध मानव संसाधनों की आवश्यकता होगी। मैं चाहता हूं कि यह मौजूद रहे और थोड़े से समन्वय और सहयोग से मुझे लगता है कि हम इसे दूर कर सकते हैं।

मूल "एपीआई" कोड: https://github.com/jupyterhub/binderhub/blob/master/examples/binder-api.py

ठीक है, मुझे लगता है कि यह निश्चित रूप से एक ट्रैक्टेबल चीज है। प्रतिक्रिया सुनने के बाद मेरे विचार:

1. ऐसा लगता है कि इस एपीआई को इस क्रिया में कॉल करना ठीक है (लोग अभी भी इसका दुरुपयोग कर सकते हैं, लेकिन मुझे लगता है कि यह एक सैद्धांतिक जोखिम है)।
2. चीजों को मॉड्यूलर रखने के लिए इस क्रिया के बाहर बाइंडर के लिंक के साथ पीआर पर टिप्पणी करने के बारे में बात की जा सकती है। बाइंडर इसे आसान बनाता है, इसलिए इसे अपने वर्कफ़्लो में इस तरह शामिल करना आसान है:

यह उदाहरण पिछले हफ्ते जीथब ब्लॉग में भी दिखाया गया था!

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. मुझे अतिरिक्त क्रेडिट के बारे में सोचना होगा। यह दिलचस्प है, मुझे लगता है कि मैं इसे इस क्रिया में नहीं बेक करूंगा क्योंकि रेपो2डॉकर के चलने के बाद यह एक डाउनस्ट्रीम कदम हो सकता है।

कृपया मुझे बताएं कि क्या कोई प्रश्न या प्रतिक्रिया है। मैं mybinder.org कैशिंग प्रक्रिया को आसान बनाने के लिए एपीआई कॉल में बेक करने की प्रक्रिया शुरू करूंगा।

@choldgraf मैंने यह कोशिश की लेकिन कंटेनर बनाने और इसे अपनी रजिस्ट्री में धकेलने की तुलना में उपयोगकर्ता अनुभव का आनंद नहीं लिया। जब एपीआई का उपयोग करते समय चीजें विफल हो जाती हैं तो यह उतना पारदर्शी नहीं होता है, आप यह भी नहीं जानते हैं कि निर्माण में लंबा समय क्यों लग रहा है या इसके कारण क्या है। मैंने इस रेपो के लिए इसका उपयोग करने की कोशिश की, उदाहरण के लिए और पाया कि निर्माण का समय वास्तव में काफी लंबा है (क्रियाओं में निर्माण की तुलना में) - सुनिश्चित नहीं है कि ऐसा क्यों है।

अभी के लिए मेरे पास लोगों को कैश करने के तरीके के रूप में अपनी रजिस्ट्री के साथ क्रियाओं में निर्माण करने के लिए रीडमे पर एक सिफारिश है, लेकिन mybinder.org को स्थगित करने का एक उदाहरण भी दिखाएं।

कोई प्रतिक्रिया या अधिक विचार सुनकर खुशी हुई

हम्म - यह दिलचस्प है। क्या आप इस पर थोड़ा और विस्तार कर सकते हैं:

जब एपीआई का उपयोग करते समय चीजें विफल हो जाती हैं तो यह उतना पारदर्शी नहीं होता है

क्या यह एक बाइंडर मुद्दा है? कुछ ऐसा जिसे सुधारने के लिए बेहतर त्रुटि लॉगिंग की आवश्यकता है?

अभी के लिए, वह भी एक ऐसा है जिसके बारे में मैं निश्चित नहीं हूँ। mybinder.org Google कंटेनर रजिस्ट्री पर चलता है, जो मुझे लगता है (?) Dockerhub से विशेष रूप से धीमी या तेज नहीं चलना चाहिए। क्या ऐसा हो सकता है कि डॉकरहब ने परतों को कैश किया हो या ऐसा कुछ?

मुझे लगता है कि, सामान्य तौर पर, कस्टम व्यक्तिगत रजिस्ट्री का उपयोग करना बाइंडर के साथ आदर्श नहीं है क्योंकि यह उन लोगों के लिए तैयार है जो डॉकर से अपरिचित हैं, इसलिए मुझे नहीं लगता कि कस्टम रजिस्ट्रियां एक महान दीर्घकालिक समाधान है (हालांकि मुझे लगता है कुछ ऐसे शोधकर्ता हैं जो तकनीकी रूप से अधिक जानकार हैं जो इसे बहुत उपयोगी पाएंगे!)