Repo2docker-action: MyBinder अभी भी छवि को खींचने के बजाय बनाता है

इस परियोजना में अपना पहला अंक खोलने के लिए धन्यवाद! ओपन सोर्स प्रोजेक्ट्स के लिए इस तरह की सगाई जरूरी है! आलिंगन:

यदि आपने पहले से ऐसा नहीं किया है, तो जुपिटर की आचार संहिता देखें । साथ ही, कृपया समस्या टेम्पलेट का पालन करने का प्रयास करें क्योंकि यह अन्य समुदाय के सदस्यों को अधिक प्रभावी ढंग से योगदान करने में मदद करता है।

आप हमारे प्रवचन मंच में शामिल होकर अन्य जोवियन से मिल सकते हैं। वहाँ एक परिचय सूत्र भी है जहाँ आप रुक कर नमस्ते कह सकते हैं! :लहर:

जुपिटर समुदाय में आपका स्वागत है! टाडा:

मुझे पता है कि बाइंडर रेपो2डॉकर का उपयोग करता है, जो कॉन्फ़िगरेशन फ़ाइलों के लिए आपके रिपॉजिटरी को स्कैन करेगा जिसमें निम्न बिल्ड प्राथमिकता है

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

ओह मेरी क्षमा याचना में थोड़ी सी गलतफहमी थी।

ऐसा लगता है कि आप MyBinder को छवि को कैश करने के लिए मजबूर करने के लिए एक छवि बनाने के लिए मजबूर करने का प्रयास कर रहे हैं। कृपया ध्यान रखें कि यदि आपके रेपो में कोई अतिरिक्त प्रतिबद्धता है तो कैश अमान्य है। साथ ही, यह MyBinder कैशिंग क्षमता और नियमों के अधीन है, जो समय के साथ बदल सकते हैं।

यह मेरी समझ के अनुसार आपकी छवि के सार्वजनिक रूप से दृश्यमान होने से बिल्कुल भी संबंधित नहीं होना चाहिए। मैंने एक ऐसे दोस्त को टैग किया जिसके पास इस बारे में अधिक जानकारी है।

यदि आप एक नोटबुक शुरू करने के लिए लगातार दो बार mybinder.org का उपयोग करने का प्रयास करते हैं (इस क्रिया पर निर्भर नहीं) तो क्या यह हर बार बनता है?

हां - बाइंडर प्रतिबद्ध हैश के आधार पर छवि का पुनर्निर्माण करेगा, इसलिए यदि आप रेपो को बिल्कुल बदल रहे हैं, तो एक नया निर्माण ट्रिगर होगा, भले ही आप कॉन्फ़िगरेशन फ़ाइल नहीं बदल रहे हों

अच्छा ऐसा है। हालांकि मैं इस कार्रवाई को हर प्रतिबद्धता पर फिर से चला रहा हूं। तो अगर मैं बाइंडर लॉन्च करने से पहले डॉकर छवि अपलोड होने की प्रतीक्षा करता हूं, तो क्या मुझे लगभग तुरंत स्टार्टअप नहीं देखना चाहिए?

हम्म - तो repo2docker कार्रवाई सिर्फ एक छवि बनाता है और इसे एक भंडार में धकेलता है, यह विशेष रूप से बाइंडर के साथ कुछ भी नहीं करता है। आपको एक बाइंडर रिपोजिटरी को कॉन्फ़िगर करने की आवश्यकता होगी जो _puls_ जहां से repo2docker-action धक्का दे रहा है, और उस स्थिर को छोड़ दें ताकि बाइंडर हर बार इसे फिर से न बना सके।

बस यह जाँचने के लिए कि क्या मैं आपकी अंतिम टिप्पणी को सही ढंग से समझता हूँ:

1. मेरे पास environment.yml साथ एक अलग शाखा/रेपो हो सकता है और एक पैकेज रिपोजिटरी को धक्का देने वाली क्रिया हो सकती है।
2. मुख्य शाखा में एक binder/Dockerfile जिसकी एकमात्र सामग्री लाइन FROM repo/package:latest ।

@choldgraf @robertodr नहीं वास्तव में इस कार्रवाई कैश MyBinder.org के लिए सीधे बनाता करने की क्षमता है लेकिन, अगर बनाने कार्रवाई समाप्त होता है आप के लिए प्रतिबद्ध है कि उसके बाद कैश तुरंत अवैध हो जाएगा।

मैं देख रहा हूं कि आप पहले गलत ध्वज का उपयोग कर रहे थे और आपको MYBINDERORG_CACHE https://github.com/ENCCS/veloxchem-workshop/commit/eeb4832cd8f8de1400a0a8fe16b113675dd630b2#diff -3f922dcd4f5c4cc1fbecda1dbf8 का उपयोग करना चाहिए था।

क्या यह अब काम करता है?

क्या यह MYBINDERORG_CACHE या BINDER_CACHE के साथ MYBINDERORG_TAG ? ऐसा लगता है कि यह अब काम कर रहा है, लेकिन इसकी सबसे अधिक संभावना है क्योंकि मैंने नोटबुक्स को एक-दो बार छोटे उत्तराधिकार में शुरू किया है: facepalm:

@robertodr मैं इस उदाहरण के साथ

@hamelsmu वाह, यह क्रिया मुझे याद की तुलना में कूलर है

वाह, हाँ, मैं अब काफी मूर्खतापूर्ण महसूस कर रहा हूँ... मुझे लगता है कि मैंने छवि को GHCR पर धकेलने के लिए इसे प्राप्त करने की कोशिश की और उम्मीद की कि यह MyBinder.org पर स्वचालित रूप से उपयोग करेगा। फिर उसे ठीक करने की कोशिश की और विकल्प नाम मिलाए गए: facepalm:

एक तरफ, BINDER_CACHE ने भी काम किया। हालांकि, मैं जिस विशिष्ट रेपो के साथ काम कर रहा हूं वह नोटबुक को स्टोर करने के लिए एलएफएस का उपयोग करता है और उन्हें ठीक से चेक नहीं किया जाएगा।

ठीक है अच्छा है! मैं तब इस मुद्दे को बंद कर दूंगा। यह मेरे लिए एक अच्छा रिफ्रेशर भी था क्योंकि मैंने कुछ समय में इस रेपो को नहीं देखा था।