संबंधित अनुरोध: #2566

मैंने इस पर काम शुरू कर दिया है।
#2566 पर टिप्पणियों को ध्यान में रखते हुए, क्या हम --values ​​या --set (या दोनों?)

मेरे द्वारा खोले गए अंक ( #3198 ) में एक अच्छा उपयोग मामला वर्णित है, जिसमें मैं ऐसा करने में सक्षम होना चाहता हूं:

helm package --version 1.2.3 --set image.tag 1.2.3

इस तरह चार्ट संस्करण और डॉकर छवि संस्करण एक ही हैं।

मैंने अभी-अभी पहला ड्राफ्ट पूरा किया है और इसके लिए एक पीआर पोस्ट किया है।

@ngeor , @sslavic मेरे द्वारा सबमिट किया गया PR --set और --values ​​दोनों विकल्पों को जोड़ता है, क्या आप कृपया एक नज़र डाल सकते हैं?

नमस्ते @adshmh , अच्छा लग रहा है; दुर्भाग्य से मुझे नहीं पता गो लेकिन मैं देख रहा हूं कि आपने इसे परीक्षण मामलों और सभी के साथ कवर किया है, इसलिए शायद यह वही करता है जो यह कहता है :) धन्यवाद!

यह सुविधा कब उपलब्ध होगी? 2.9.0 में?

3471 2.9 के लिए समय सीमा से चूक गया, इसलिए यह 2.10 में होगा।

इसे फिर से खोलना, क्योंकि #3471 को बैक आउट करने की आवश्यकता है।

यह संग्रह पैकेज में टिप्पणियों/आदि का क्या करता है? उदाहरण के लिए, क्या वे छीन लिए गए हैं या अकेले छोड़ दिए गए हैं या ??

वर्तमान में मैं yq के साथ वही काम करने की कोशिश कर रहा हूं लेकिन यह प्रसंस्करण के बाद अंतिम मानों को डंप करता है। यानी, सभी टिप्पणियाँ, संगठन के लिए रिक्त पंक्तियाँ, आदि चले गए हैं।

3471 ने सभी टिप्पणियों को हटा दिया, यही वजह है कि हमें उस पीआर को वापस करने की जरूरत थी। अधिक जानकारी के लिए देखें https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783

2.10 से वापस लाया गया

इसके बारे में कुछ खबर?
धन्यवाद

ऊपर की तरह; #3471 में बग्स को ठीक करने के लिए किसी ने फॉलो-अप पर काम नहीं किया है, इसलिए इसे लागू नहीं किया गया है। यदि आप मान फ़ाइल से टिप्पणियों को छीनने के साथ ठीक हैं तो आप हेल्म को फोर्क करने और # 3471 के खिलाफ संकलित करने के लिए स्वागत से अधिक हैं।

क्या यह किया गया है? मैंने 2.11.0 और 2.12.0 संस्करणों पर कोशिश की उनमें से कोई भी helm package --set... नहीं है

+1। यह वास्तव में सीआई में पैकिंग से पहले मूल्यों के यम को रोकने और अपग्रेड करने में हमारी मदद करेगा।

+1

--सेट-स्ट्रिंग भी उपयोगी हो सकती है, क्यों न इंस्टॉल/अपग्रेड में मौजूद सभी ओवरराइड विकल्पों की अनुमति दी जाए।
पैकेज कमांड के मानों को ओवरराइड करने के लिए उपयोग किए गए समान कोड को बस निष्पादित करें, यह समझ में आता है कि पैकेज में ओवरराइड मान होंगे - उन झंडे को इंस्टॉल/अपग्रेड के साथ ही साझा किया जाना चाहिए।

2.13.1 में ऐसी सुविधा भी नहीं है, क्या इसके लिए कोई समय सारणी है?

जैसा कि पहले उल्लेख किया गया है, वर्तमान में कोई भी इस पर काम नहीं कर रहा है और कोई समय सारिणी नहीं है कि कोई फिक्स कब उपलब्ध होगा। इसे लेने के लिए स्वतंत्र महसूस करें। विचारों के लिए #3471 पर एक नज़र डालें।

हेल्म 3 में लागू किया गया । समापन!

कोड को देखते हुए, ऐसा प्रतीत होता है कि #3471 ने गलती से हेल्म 3 में अपना रास्ता बना लिया था, लेकिन इस टिप्पणी के कारण हमने हेल्म 2 के लिए ऐसा नहीं किया था: https://github.com/helm/helm/pull/3471#issuecomment -381779783

मैं इस सुविधा अनुरोध को फिर से खोल रहा हूं क्योंकि हम https://github.com/helm/helm/pull/7201 के साथ हेल्म 3 में --set और --values ​​​​झंडे हटा रहे हैं। उन्होंने कभी भी वैसे भी काम नहीं किया... --set या --values के माध्यम से सेट की गई किसी भी चीज़ को कभी भी पैकेज में इंजेक्ट नहीं किया गया था, और इसने helm package के साथ कुछ घातक प्रतिगमन पेश किए, अर्थात् यह तथ्य कि यह छीन लिया गया था value.yaml से टिप्पणियां निकालें, जिसे कई समुदाय सदस्य दस्तावेज़ीकरण के रूप में उपयोग करते हैं।

हो सकता है कि मैं गलत समझ रहा हूं, लेकिन मैं खुशी से --set मान सेट करने के लिए पैकेज के साथ उपयोग कर रहा हूं और यह 3.0.0 से 3.0.2 तक बहुत अच्छा काम करता है, निश्चित रूप से #7201 में वर्णित "नो-ऑप" नहीं है।

मेरी पाइपलाइन 3.0.3 से टूटी हुई है। यह 3.0.2 में काम कर रहा था। इसे उपयोगी क्यों नहीं माना जाता है, यदि हमारे पास --version और --app-version है। --ऐप-संस्करण से मिलान करने के लिए हमें छवि और टैग को कैसे संपादित करना चाहिए? दे घुमा के ?

कोड को फिर से देखते हुए, आप @lukaslarson और @maxhillaert सही हैं। हालाँकि, यह अभी भी एक विशेषता थी जिसे वापस करने का इरादा था क्योंकि इसने पैकेज की मान फ़ाइल से सभी टिप्पणियों को हटा दिया था। इसे हेल्म 2 में हटा दिया गया था, लेकिन गलती से हेल्म 3 में अपना रास्ता बना लिया। इसे कभी भी शिप करने का इरादा नहीं था।

अगर कोई टिप्पणी को बरकरार रखने वाले #3471 को फिर से लागू करने पर काम करना चाहता है, तो हमें पीआर को देखकर खुशी होगी।

@bacongobbler इसने हमारे लिए कुछ सामान तोड़ दिया। मुझे पीआर पर काम करने में दिलचस्पी होगी, हालांकि यह गैर-तुच्छ लगता है, इसलिए मैं दृष्टिकोण की जांच करना चाहता हूं।

ऐसा लगता है कि gopkg.in/yaml.v3 राउंड ट्रिप पर जाते समय टिप्पणियों को बनाए रखने का समर्थन करता है। मेरा प्रस्ताव Values एक yaml Node बनाने का होगा। फिर, मूल्यों को जोड़ते समय, नेस्टेड मानचित्रों के बजाय पार्स किए गए आउटपुट के पेड़ पर चलें। यह निश्चित रूप से कम एर्गोनोमिक है लेकिन टिप्पणियों को संरक्षित करने का सबसे अच्छा तरीका है।

यह थोड़ी समस्या है क्योंकि हम हर जगह sigs.k8s.io/yaml का उपयोग कर रहे हैं जिसे अंतर्निहित lib के v2 पर पिन किया गया है। कम से कम, इसे एक अलग निर्भरता के रूप में पेश करने की आवश्यकता होगी, जो कि यक की तरह है। सुनिश्चित नहीं है कि यम से संबंधित हर चीज को छूने से बचने के लिए यहां सबसे अच्छा तरीका क्या है।

ऐसा लगता है कि yaml.v3 में माइग्रेट करना सबसे अच्छा विकल्प है, इसलिए ऐसा लगता है कि आप सही रास्ते पर हैं।

यदि आप हेल्म के PoC/फोर्क पर काम करना शुरू करना चाहते हैं जो sig.k8s.io/yaml के बजाय yaml.v3 का उपयोग करता है, तो यह आगे का एक अच्छा रास्ता होगा। इस तरह हम master की तुलना में इसकी कार्यक्षमता का मूल्यांकन करना शुरू कर सकते हैं।

एक बार जब हमने यह स्थापित कर लिया कि yaml.v3 आगे का सबसे अच्छा मार्ग है, तो हम यह पता लगा सकते हैं कि एसडीके के दृष्टिकोण से कैसे आगे बढ़ना है।

क्या यह आपको अनब्लॉक करने में मदद करता है?

@jmcelwain क्या आप इस पर सक्रिय रूप से काम कर रहे हैं? यदि नहीं तो मैं इसे सहर्ष संभाल लूंगा।

@ sreya92 काम में व्यस्त हो गई। यहां मैंने छोड़ा था: yaml.v3 पर स्विच करना ज्यादातर आसान था, यहां इस बिट के अपवाद के साथ। यह सुनिश्चित नहीं था कि इसे संभालने का सबसे अच्छा तरीका निर्भरता को बेचने और इसे v3 में अपडेट किए बिना था।

ऐसा लगता है कि अपग्रेड करने के लिए कुछ काम किया गया था , लेकिन मुद्दों आदि में कोई अन्य जानकारी नहीं है, और मैंने किसी मुद्दे को खोलने की जहमत नहीं उठाई। दूसरा विकल्प सिर्फ दोनों निर्भरताओं को रखना होगा, लेकिन यह सकल लगता है।

मेरी व्यक्तिगत राय यह होगी कि यह इस मुद्दे के लिए एक अवरोधक है, जब तक कि अनुरक्षकों को यह नहीं लगता कि समान कामों की लगभग दो प्रतियां ले जाना सार्थक है। निश्चित नहीं है कि एलओई यहाँ क्या है, लेकिन हमें शायद github.com/ghodss/yaml को v3 में लाने के लिए काम करना चाहिए और k8s में विक्रेता संस्करण को भी अपग्रेड करना चाहिए। इससे यह सब काफी आसान हो जाएगा।

वहां अपग्रेड पथ की संभावना के बारे में पूछताछ करने के लिए https://github.com/ghodss/yaml/issues/61 खोला। कुछ और जारी रखने से पहले उनसे वापस सुनने का इंतजार करेंगे - निर्भरता को अपग्रेड करना आईएमओ के अन्य विकल्पों के लिए बेहतर है।

@jmcelwain https://github.com/ghodss/yaml में बड़ी मात्रा में कोड नहीं है, 2017 से अनुपयोगी पुल अनुरोध हैं: https://github.com/ghodss/yaml/pulls , और कोड MIT है लाइसेंस प्राप्त।

क्या यह निर्भरता वास्तव में अपना भार खींच रही है? यह कुछ मार्शलिंग हेल्पर्स हैं, लेकिन एक ऐसे मुद्दे को पकड़ने का प्रबंधन कर रहे हैं, जिसे हल करने पर कई परियोजनाओं की क्षमता में सुधार हो सकता है ताकि बिल्ड-टाइम पर पैकेज डिफॉल्ट को गतिशील रूप से सेट किया जा सके (हमारा उपयोग मामला संस्करण टैग को स्टोर करने के लिए कई अलग-अलग स्थानों को बनाए रखना नहीं है। किसी प्रोजेक्ट के लिए चार्ट और छवि संस्करणों को लॉक करने के लिए --set image.tag=${GIT_TAG} जैसा कुछ)।

क्या मैं सुझाव दे सकता हूं कि हम अब और इंतजार नहीं करते हैं और केवल आवश्यक कोड को हेलम में कॉपी करते हैं (मैं इसे बेचने से परेशान नहीं होगा बस इसे अवशोषित और आवश्यकतानुसार अनुकूलित करें)। मुझे लगता है कि यह इस रैपर के रखरखाव को संभालने के लिए एक बड़ी पर्याप्त परियोजना है और वाईएएमएल मार्शलिंग एक मुख्य योग्यता है (यह नहीं कह रहा कि आपको अपना खुद का पार्सर बनाए रखना चाहिए, लेकिन ...!)

चूंकि यह हमें अभी दर्द दे रहा है (और हमें हेलम 3.0.2 से अपग्रेड करना रोक रहा है) मुझे इस पर एक स्टैब लेने में खुशी होगी।

मैं उस स्थिति से बचना पसंद करूंगा। पैकेज मैनेजर और YAML पार्सर दोनों को बनाए रखने के लिए पर्याप्त अनुरक्षक नहीं हैं। यह टीम के लिए एक महत्वपूर्ण रखरखाव बोझ पेश करेगा।

@bacongobbler यह _not_ एक यमल पार्सर है। यह वास्तविक पार्सिंग करने के लिए gopkg.in/yaml.v2 का उपयोग करता है। यह उस पार्सर के चारों ओर reflect रैपर कोड की लगभग 900 लाइनें हैं। समस्या यह है कि वे gopkg.in/yaml.v3 का उपयोग नहीं करते हैं जो इस मुद्दे को हल करेगा।

ऐसा लगता है कि इस मामूली इंटरमीडिएट को आपकी वास्तविक निर्भरता में उपयोग करने का रखरखाव बोझ एक बड़ा बोझ है जो इस बिट कोड को बनाए रखता है।

जैसा कि पहले सूत्र में बताया गया है, कृपया बेझिझक एक पीआर अपस्ट्रीम का प्रस्ताव दें जो ghodss/yaml को yaml.v3 में अपडेट कर दे। यदि वे इसे स्वीकार नहीं करेंगे, तो बेझिझक परियोजना को छोड़ दें और इसे बनाए रखें यदि आपको लगता है कि आप रखरखाव का बोझ उठा सकते हैं।

हालांकि मुझे स्पष्ट होने दें: हम _विल नहीं_ पुल अनुरोधों को स्वीकार करते हैं जो कि कांटा और विक्रेता घोड्स/यम को हेल्म में रखते हैं। हम केवल एक सुविधा का समर्थन करने के लिए संपूर्ण गो लाइब्रेरी के अतिरिक्त रखरखाव का बोझ नहीं उठा सकते।

@bacongobbler कृपया मेरे पीआर को यहां देखें: https://github.com/helm/helm/pull/7963

यह 900 लाइनों का कोड है जिसमें परीक्षण शामिल हैं और अनावश्यक कार्यक्षमता हटा दी गई है।

अभी आप इस बात पर निर्भर हैं कि जो मैंने वहां जोड़ा है उससे कहीं अधिक बड़े पदचिह्न के साथ एक अपेक्षाकृत अनियंत्रित पुस्तकालय की तरह दिखता है।

केवल एक सुविधा का समर्थन करने के लिए एक संपूर्ण गो लाइब्रेरी

आप इस संपूर्ण गो लाइब्रेरी से सभी एक फ़ंक्शन का उपयोग करते हैं, और ऐसा करने के लिए आप एक स्थायी कांटा बनाने के प्रयास में गए हैं जो आगे यह अस्पष्ट करता है कि कोड कहां से आ रहा है।

अगर आपको लगता है कि आप रखरखाव का बोझ उठा सकते हैं तो परियोजना को फोर्क करने और इसे बनाए रखने के लिए स्वतंत्र महसूस करें।

मेरा मतलब है कि आप पहले से ही इस कोड का एकल-उद्देश्य वाला कांटा चला रहे हैं। यदि परियोजना को छोड़ दिया जाता है तो आप मूल लेखक से किसी भी रखरखाव से वास्तव में लाभ नहीं उठा रहे हैं।

यदि आप चाहें तो मैं अपने पीआर में कोड की वह छोटी राशि ले सकता हूं और इसे रेपो में रख सकता हूं और कह सकता हूं कि मैं इसे बनाए रखूंगा (और मैं ऐसा करने का प्रयास करूंगा), लेकिन यह मूर्खतापूर्ण लगता है।

हालांकि मुझे स्पष्ट होना चाहिए: हम पुल अनुरोधों को स्वीकार नहीं करेंगे कि फोर्क और विक्रेता घोड्स/यमल हेल्म में हैं।

रिकॉर्ड के लिए, जब तक मैं इसे पढ़ता हूं, तब तक मैंने उस पीआर को पहले ही धक्का दे दिया था, इसलिए मुझे आशा है कि आप पुनर्विचार करेंगे क्योंकि मुझे लगता है कि आपके पास 'विक्रेता' और 'संपूर्ण गो लाइब्रेरी' के बारे में एक कैश्ड विचार है (जिससे मैं अक्सर सहमत हो सकता हूं) ) शामिल कोड को देखे बिना। लेकिन आइए पीआर पर विचाराधीन वास्तविक कोड पर चर्चा करें। अगर यह मदद करता है तो मुझे इस कोड के लिए एक कोड स्वामी बनकर खुशी हो रही है। आइए कल्पना करें कि मैंने इसे एक योगदान के रूप में लिखा था... मैंने किया।

शायद वे इसे मर्ज कर देंगे: https://github.com/ghodss/yaml/pull/62

दूसरा विकल्प जिसे मैंने संक्षेप में खोजा था, वह था YAML को JSON रूपांतरण में किसी अन्य निर्भरता के माध्यम से बदलने या कुछ मध्यवर्ती प्रारूप के माध्यम से क्रमबद्ध करने की संभावना। मैं यह जानने के लिए गो पारिस्थितिकी तंत्र से पर्याप्त परिचित नहीं हूं कि क्या यह एक व्यवहार्य मार्ग है - मुझे कुछ आश्चर्य हुआ कि जब मैंने संक्षेप में देखा तो मुझे अधिक क्रमबद्धता-प्रकार के काम नहीं मिले।

जब हम हेल्म पैकेजिंग को स्वचालित करने के लिए इसका उपयोग करते हैं तो कोई विचार जब हम --सेट वापस कर सकते हैं। यह हेल्म 3.0.2 में था और अब चूंकि अपडेट करना अब समर्थित नहीं है।

हम अभी भी https://github.com/ghodss/yaml/pull/62 विलय होने पर अवरुद्ध हैं।

कोड को फिर से देखते हुए, आप @lukaslarson और @maxhillaert सही हैं। हालाँकि, यह अभी भी एक विशेषता थी जिसे वापस करने का इरादा था क्योंकि इसने पैकेज की मान फ़ाइल से सभी टिप्पणियों को हटा दिया था। इसे हेल्म 2 में हटा दिया गया था, लेकिन गलती से हेल्म 3 में अपना रास्ता बना लिया। इसे कभी भी शिप करने का इरादा नहीं था।

अगर कोई टिप्पणी को बरकरार रखने वाले #3471 को फिर से लागू करने पर काम करना चाहता है, तो हमें पीआर को देखकर खुशी होगी।

क्या इससे कोई फर्क पड़ता है कि टिप्पणियां हटा दी गई हैं, अगर --सेट का उपयोग करने की कोई चेतावनी है तो मुझे टिप्पणियों की परवाह नहीं है।

हमें अभी भी घोड्स/यमल#62 का विलय होने से रोक दिया गया है।

मुझे लगता है कि 3.0.2 का उपयोग करने के साथ फंस गए थे :(

3471 ने टिप्पणियां छीन लीं, भले ही आपने --set उपयोग किया हो या नहीं, इसलिए इसने उन उपयोगकर्ताओं को तोड़ दिया जिन्होंने कभी इस सुविधा का उपयोग नहीं किया। इसने सभी के लिए पश्चगामी संगतता को तोड़ा। इसलिए इसे एक चेतावनी के साथ फिर से पेश नहीं किया जा सकता है, और यही कारण है कि हम एक उचित फिक्स अपस्ट्रीम पर प्रतीक्षा कर रहे हैं।

इसलिए हमें 3.0.2 . पर टिके रहना है

हमें अभी भी घोड्स/यमल#62 का विलय होने से रोक दिया गया है।

लेकिन चूंकि ऐसा लगता है कि यह निर्भरता अब और नहीं बनी हुई है, हो सकता है कि फोर्कड संस्करण का उपयोग करना बेहतर होगा, है ना?

स्विच करना एक अच्छा विचार है - लेकिन इसे हेल्म 4 के लिए स्थगित किया जाना चाहिए। किसी को वाईएएमएल पार्सर्स को स्विच करने के लिए एक विशेष मुद्दा दर्ज करना चाहिए ताकि हम उसे हेल्म 4 प्रक्रिया के लिए ट्रैक कर सकें।

हालांकि मुझे स्पष्ट होना चाहिए: हम पुल अनुरोधों को स्वीकार नहीं करेंगे कि फोर्क और विक्रेता घोड्स/यमल हेल्म में हैं। हम केवल एक सुविधा का समर्थन करने के लिए संपूर्ण गो लाइब्रेरी के अतिरिक्त रखरखाव का बोझ नहीं उठा सकते।

ऐसा लगता है कि https://github.com/ghodss/yaml अब बनाए नहीं रखा गया है, और https://github.com/ghodss/yaml/pull/62 पर जीवन पर कोई संकेत नहीं है, क्या यह इस स्थिति पर पुनर्विचार करने लायक है, और https://github.com/helm/helm/pull/7963 का पुनर्मूल्यांकन कर रहे हैं?

हम केवल एक सुविधा के लिए संपूर्ण YAML पार्सिंग लाइब्रेरी का समर्थन करने के रखरखाव के बोझ को उठाने में रुचि नहीं रखते हैं।

मैं समुदाय से आग्रह करता हूं कि वह परियोजना का समर्थन करने, परियोजना को फोर्क करने, या टिप्पणियों को संरक्षित करने वाली एक नई पुस्तकालय खोजने के लिए तैयार अनुरक्षकों के एक नए सेट को खोजने के लिए घोड्स / यमल के मौजूदा अनुरक्षकों के साथ काम करने पर विचार करें।

तो यह क्या होगा?

• घोड्स/वाईएएमएल का समर्थन करने के लिए नए अनुरक्षक खोजें!
• किसी को घोडस/वाईएएमएल फोर्क करने के लिए ढूंढें और वाईएएमएल.वी3 का उपयोग करें (और इसका समर्थन करना जारी रखें) !!
• सीधे YAML.v3 का उपयोग करें
• YAML पार्सर्स को हेलम 4 के लिए स्विच करने का प्रस्ताव

एक संपूर्ण YAML पार्सिंग लाइब्रेरी

यह यहां शामिल कोड के दायरे को गलत तरीके से प्रस्तुत करता है। यह अन्य पार्सर्स के आसपास कुछ रैपर हैं।

हम केवल एक सुविधा के लिए संपूर्ण YAML पार्सिंग लाइब्रेरी का समर्थन करने के रखरखाव के बोझ को उठाने में रुचि नहीं रखते हैं।

शायद यह भ्रम बहुत कुछ समझाता है - पार्सर https://github.com/go-yaml/yaml है, न कि घोड्स/वाईएएमएल। https://github.com/ghodss/yaml से:

गो-यमलो के चारों ओर एक आवरण

तो सरल उपाय यह है: बस रैपर का उपयोग करना बंद कर दें।

कुछ व्यवहारों पर "रैपर्स" का गहरा प्रभाव पड़ता है। प्रोजेक्ट में कुछ समय पहले पार्सर्स (और रैपर लाइब्रेरी) को स्विच करने के बाद, मुख्य अनुरक्षकों को उनके बीच की छोटी-छोटी विसंगतियों के बारे में अच्छी तरह से पता होता है, जिससे वे उच्च-स्तरीय संगतता मुद्दों का उत्पादन करते हैं।

एक संभावना है कि हम घोडस/यमल के कांटे का उपयोग करने पर विचार कर सकते हैं यदि और केवल तभी जब उस कांटे के मालिक निरंतर रखरखाव के लिए प्रतिबद्ध हों।

शायद मैं और अधिक सटीक हो सकता हूं - छोड़े गए रैपर लाइब्रेरी का उपयोग करना बंद करें, और समकक्ष/समान रैपिंग व्यवहार को हेल्म में करें, जो कि https://github.com/helm/helm/pull/7963 लगभग ~ 250 एलओसी प्लस में करता है परीक्षण।

हां, आदर्श रूप से इसके बजाय कोई व्यक्ति घोडस/यमल में ठीक करेगा, लेकिन अब इसका रखरखाव नहीं किया जाता है। निश्चित रूप से विकल्प हेल्म 4 तक इंतजार नहीं कर रहा है?

मुझे लगता है कि फोर्किंग शायद सबसे अच्छा विकल्प है, आईएमओ; ऐसा लगता है कि 2019 की शुरुआत से @ghodss ने GH पर कोई गतिविधि नहीं की है, और रेपो के लिए अंतिम प्रतिबद्धता डेढ़ साल पहले (@bradfitz द्वारा) थी। अंतिम (केवल) रिलीज़ 2017 में हुई थी। यदि कोड में कोई गुप्त सुरक्षा समस्याएँ हैं, तो वे मुख्य पर ठीक नहीं होने जा रहे हैं।

अगर कोई इसे बनाए रखने के लिए प्रतिबद्ध है तो मैं एक कांटा अपनाने की जोरदार वकालत करता हूं; मुझे मरणासन्न और परित्यक्त पैकेज का उपयोग जारी रखने के सापेक्ष कोई डाउनसाइड नहीं दिखता है। मैं मानता हूं कि एक अलग रैपर में जाने से एक बड़े बदलाव के रूप में अधिक समझ में आता है (एक भारी लिफ्ट की तरह लगता है कि यह आसानी से हेल्म 4 चीज हो सकती है, लेकिन मैं आगे अनुमान लगाने वाला नहीं हूं), लेकिन मुझे लगता है कि इसे हल किया जा सकता है replace लाइन के साथ go.mod ।

अगर कोई और भी है तो मैं एक कांटा सह-रखरखाव में मदद करने के लिए प्रतिबद्ध हूं; मेरे पास अभी इसे स्वयं करने के लिए पर्याप्त बैंडविड्थ नहीं है, लेकिन मेरे पास योगदान करने के लिए पर्याप्त है।

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

नमस्ते
मैंने अभी एक प्लगइन बनाया है जो पैकेजिंग करते समय मान सेट करने की अनुमति देता है। फिलहाल यह केवल set ध्वज का समर्थन करता है (क्योंकि मुझे इसकी आवश्यकता थी :sweat_smile: ) लेकिन मैं अन्य झंडे जोड़ना चाहता हूं। यदि आप चाहें तो पीआर को आगे बढ़ाने में संकोच न करें या इसे सुधारने के लिए टिप्पणी जोड़ें।
शुक्रिया

बस अगर कोई पीछा नहीं कर रहा है, तो घोड्स/यमल#62 में एक अनुरक्षक से संपर्क करने में कुछ प्रगति हुई है, इसलिए उम्मीद है कि हम जल्द ही कुछ अच्छी खबर सुनेंगे!

इस मुद्दे को पुराने के रूप में चिह्नित किया गया है क्योंकि यह 90 दिनों से बिना किसी गतिविधि के खुला है। यदि आगे कोई गतिविधि नहीं होती है तो यह थ्रेड 30 दिनों में अपने आप बंद हो जाएगा।

निश्चित रूप से बासी नहीं। मैं https://github.com/ghodss/yaml/pull/62 के साथ अनुवर्ती कार्रवाई के लिए समय निकालने की कोशिश कर रहा हूं और देखें कि क्या हम इस मुद्दे पर प्रगति को अनब्लॉक करने के लिए विलय करने में मदद कर सकते हैं। चूंकि मेरे संगठन ने हेल्म पर हमारी निर्भरता बढ़ा दी है, इसलिए हम प्रति-सीआई बिल्ड पैकेज्ड चार्ट में मूल्यों को सेंकने में सक्षम होना चाहते हैं।

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

जब हमारे पास साझा करने के लिए और जानकारी होगी, तो हम थ्रेड को अपडेट करेंगे।

वर्कअराउंड के रूप में, मैंने पैकेजिंग से पहले अपने हेल्म चार्ट को अपडेट करने के लिए https://github.com/mikefarah/yq का उपयोग किया है:

yq w -i values.yaml version $(Build.BuildNumber)

हमारे सीआई में हम एक ही पाइपलाइन में ऐप/डॉकर छवि और चार्ट बनाते हैं (यह सुनिश्चित करने के लिए कि ऐप और चार्ट एक ही संस्करण के साथ विकसित होते हैं)। चार्ट के लिए डिफ़ॉल्ट मान पहले बनाए गए छवि संस्करण पर निर्भर करता है।

yq वर्कअराउंड को आसानी से एक पाइपलाइन में एकीकृत किया जा सकता है, लेकिन यह अजीब लगता है कि यह उपयोग केस सही ढंग से हेलम द्वारा कवर नहीं किया गया है!

तो वे पैकेज चरण के दौरान/पहले image.tag सेट करने के लिए पतवार के साथ कोई एकीकृत तरीका नहीं हैं?

संपादित करें : मेरे मामले में यह समाधान मिला, हमें छवि टैग के लिए चार्ट.एपवर्सन का उपयोग करने की आवश्यकता है क्योंकि हम चार्ट को उसी संस्करण के साथ पैकेज करते हैं।

2 संपादित करें : चार्ट। ऐप वर्जन / साझा चार्ट के साथ काम न करें (एक से अधिक छत्र चार्ट में उपयोग किए जाने वाले स्प्रिंग-बूट चार्ट का विस्तार करें)

मेरा निष्कर्ष : पैकेज चरण के दौरान वास्तव में image.tag सेट करने की आवश्यकता है

इस फीचर के बारे में कोई खबर?