Helm: चार्ट.yaml . को संपादित किए बिना इंस्टॉल या अपग्रेड के दौरान .Chart.AppVersion सेटिंग का एक साधन प्रदान करें

स्पष्टता के लिए, #3555 ओपी द्वारा बंद कर दिया गया था (रेफरी https://github.com/helm/helm/issues/3555#issuecomment-63318773) निम्नलिखित टिप्पणी के साथ:

"ऐसा लगता है कि यहां बहुत से लोग 'ऐपवर्सन' फ़ील्ड को ओवरराइड करने का तरीका पूछ रहे हैं। इस मुद्दे में मूल इरादा/अनुरोध -एप-संस्करण को -वर्जन के प्रतिस्थापन के रूप में अनुमति देना है, ताकि उपयोगकर्ता चला सके ' हेल्म फ़ेच -ऐप-वर्जन = v0.15.0' और हेल्म यह पता लगाएगा कि नवीनतम चार्ट संस्करण ने ऐप वर्जन के रूप में v0.15.0 को अंतिम बार क्या निर्दिष्ट किया है और उसे प्राप्त करें।

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

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

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

मुझे यह भी लगता है कि इस तरह की कार्यक्षमता हो सकती है, और शायद सबसे अच्छा है, बाहरी उपकरण या रैपर के रूप में लागू किया गया है
हेल्म, विशेष रूप से ओसीआई परिवर्तनों को ध्यान में रखते हुए, जो मुझे लगता है कि इसे लागू करने के लिए कठिन बना देगा।"

यह बदसूरत है लेकिन यह काम करता है, हालांकि हेलम में एक अंतर्निर्मित ध्वज पसंद करेगा

sed -i "s/^version:.*$/version: $(git describe)/" chart/Chart.yaml
sed -i "s/^appVersion:.*$/appVersion: $(git describe)/" chart/Chart.yaml
helm upgrade app ./chart

काश यह और अधिक पसंद होता ....

helm upgrade --version "$(git describe)" --app-version "$(git describe)" app ./chart

@loa आपका सुझाव शीर्षक से निम्नलिखित का पालन नहीं करता है (और इसका पूरा बिंदु है"

संपादित किए बिना Chart.yaml

@timothyclarke मैं सिर्फ उपयोग-मामले को स्पष्ट करना चाहता था।

वर्तमान में बदलने की क्षमता के बिना appVersion उन्नयन पर, का परिणाम helm history है:

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.0       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.0       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.0       Upgrade complete

आदर्श रूप से चल रहा है

helm upgrade --wait --app-version "$MY_AWESOME_VERSION" app ./chart

अधिक उपयोगकर्ता के अनुकूल helm history में Wold परिणाम, जैसा कि नीचे दिया गया है। इससे पता चलता है कि चार्ट नहीं बदला है लेकिन ऐप के नए रिलीज़ हुए हैं।

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.1       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.2       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.3       Upgrade complete

क्या यह उपयोग मामला पतवार प्रक्रिया के साथ फिट बैठता है?

आदर्श रूप से, क्या कमांड लाइन के माध्यम से प्रदान किया गया ऐप-संस्करण टेम्पलेट्स ( $.AppVersion ) में भी उपलब्ध होगा?

यह इसे कुबेरनेट्स कॉन्फ़िगरेशन के मेटा डेटा में जोड़ने की अनुमति देगा।

यह अति उपयोगी होगा। "एप्लिकेशन संस्करण" के विषय पर टिप्पणी करें अर्थात ऐप क्या है, और "ऐप" आदि में एक से अधिक डॉकर छवि होने पर आप संस्करण को कैसे परिभाषित करते हैं, सीआई/सीडी में अपडेट को स्वचालित कैसे करें। मैं 2 संस्करणों को परिभाषित करके इन मुद्दों को दरकिनार करता हूं:

1. चार्ट संस्करण: टेम्पलेट के लिए _source_ का प्रतिनिधित्व करता है;
   
   
   
   • यदि टेम्पलेट स्रोत बदलता है, तो चार्ट संस्करण बदलना चाहिए; टेम्प्लेट स्रोत का अर्थ है टेम्प्लेट फ़ोल्डर, चार्ट.yaml, डिफ़ॉल्ट मान.yaml, हेलमग्नोर, नोट्स, आदि।
   
   
   • मैं चार्ट रेपो में हेल्म चार्ट को स्टोर नहीं करता क्योंकि चार्ट किसी भी समय गिट से उपलब्ध है और हेल्म इंस्टॉल के माध्यम से स्थापित किया जा सकता है
   
   
2. स्थापना संस्करण: स्थापना में उपयोग किए गए सभी मानों के संयोजन के आधार पर अद्वितीय मान, यानी सभी मान फ़ाइलों (डिक्रिप्टेड गुप्त वाले सहित) और सेट और चार्ट के डिफ़ॉल्ट मानों को मर्ज करने के बाद। मैं मूल्यों के अंतिम सेट के आधार पर इसे MD5 या SHA256 के माध्यम से निर्धारित करता हूं।

चूंकि पतवार में स्थापना संस्करण की अवधारणा नहीं है, इसलिए मैं md5 को पकड़ने के लिए ऐप संस्करण का उपयोग करता हूं।

यह यह व्याख्या करने के लिए बनाता है कि क्या स्थापित किया गया है:

REVISION    UPDATED                     STATUS      CHART           APP VERSION      DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    3efe0e3...       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    ie21b02...       Upgrade complete
3           Mon Jun  8 12:20:51 2020    superseded  spring-1.0.0    3efe0e3...       Upgrade complete
4           Mon Jun  8 12:20:51 2020    deployed    spring-1.1.0    123abcd...       Upgrade complete

अब यह बहुत स्पष्ट है कि संशोधन 1 और 3 एक ही स्थापना हैं: एक ही चार्ट स्रोत और मूल्यों का एक ही अंतिम पेड़।

यदि कोई इसे आजमाने में रुचि रखता है, तो https://github.com/scholii/sandals/blob/master/helm.py इसके लिए कुछ उपयोगी कार्य प्रदान करता है। वर्तमान में मुझे मर्ज किए गए मान प्राप्त करने के लिए ड्राई-रन के माध्यम से हैश मिलता है, और मुझे चार्ट में ऐप संस्करण को संपादित करने के लिए चार्ट को एक अस्थायी फ़ोल्डर में कॉपी करना होगा (या पैकेजिंग वर्कअराउंड का उपयोग करें, क्योंकि यह - ऐप-संस्करण का समर्थन करता है) ) तो इंस्टॉल के लिए --app-version कमाल का होगा। मैं --app-version-is-md5 जैसा कुछ भी लागू करना चाहता हूं जो सूखे-रन को अनावश्यक बना देगा, लेकिन यह किसी अन्य मुद्दे (# 8453) में होगा।

जब मैं गिट टैग yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_SHORT_SHA" का उपयोग नहीं कर रहा हूं तो मैं प्रत्येक इंस्टॉल से पहले इसका उपयोग करता हूं

जब मैं एक टैग का उपयोग करता हूं तो मैं सीआई प्रक्रिया में संशोधन को अपग्रेड करता हूं जिसका उपयोग मैं प्रत्येक इंस्टॉल yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_TAG" से पहले करता हूं
फिर संस्करण नियंत्रण के लिए अद्यतन Chart.yaml प्रतिबद्ध करें।

गिटलैब सीआई . का उपयोग करना

मुझे पता है कि ऐसे बहुत से लोग हैं जो चार्ट प्रकाशित करने से ठीक पहले ऐप संस्करण सेट करना पसंद करते हैं। लेकिन वास्तव में हम एक चार्ट प्रकाशित नहीं करना चाहते हैं, खासकर जब हम अभी भी अपने द्वारा किए गए परिवर्तनों का परीक्षण कर रहे हैं। एक देव वातावरण में स्थापित या अपग्रेड करना इस सुविधा के लिए प्राथमिक उपयोग का मामला है।

@woodcockjosh , मुझे यकीन नहीं है कि यह समस्या चार्ट संस्करण के आसपास है, लेकिन चार्ट का उपयोग करके तैनात किए गए मानव पठनीय एप्लिकेशन संस्करण (ऐपवर्सन) में से अधिक है।

मैं कहूंगा कि इस सुविधा के लिए प्राथमिक उपयोग का मामला चार्ट डिजाइनरों, सर्वर व्यवस्थापकों और देवों को यह क्षमता देने के लिए अधिक है:

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

ऊपर दिए गए दो उपयोग मामलों को कवर करके, आईएमओ, यह हेल्म चार्ट के कार्यान्वयन और उपयोग के तरीके पर बिना राय के रहने की अनुमति देगा।

स्थापना संस्करण: स्थापना में उपयोग किए गए सभी मानों के संयोजन के आधार पर अद्वितीय मान, यानी सभी मान फ़ाइलों (डिक्रिप्टेड गुप्त वाले सहित) और सेट और चार्ट के डिफ़ॉल्ट मानों को मर्ज करने के बाद। मैं मूल्यों के अंतिम सेट के आधार पर इसे MD5 या SHA256 के माध्यम से निर्धारित करता हूं।

@schollii मुझे एक उदाहरण संस्करण का विचार पसंद है, लेकिन एक निर्माता और
इंस्टॉलेशन संस्करण अद्वितीय नहीं होगा यदि केवल एप्लिकेशन कोड बदल गया है और चार्ट और/या चार्ट पर लागू मान नहीं हैं।

@rcampbel हाँ, निश्चित रूप से हम उस एप्लिकेशन का संस्करण देखना चाहते हैं जो स्थापित है। हालांकि मैं जो कह रहा हूं वह यह है कि जिन परिस्थितियों में आप ऐप वर्जन के लिए एक अलग संस्करण चाहते हैं, जो कि Chart.yaml है, यदि वह चार्ट आपका है और आप विकास स्तर के संस्करण को तैनात कर रहे हैं आवेदन पत्र। यदि यह विकास स्तर संस्करण नहीं था तो आप केवल ऐप संस्करण संख्या को Chart.yaml अंदर रख सकते थे और चार्ट के अंतिम उपयोगकर्ता उस ऐप संस्करण को डिफ़ॉल्ट ऐप संस्करण के रूप में उपयोग कर सकते थे।

यदि मैं उदाहरण के लिए नए माइक्रोसर्विसेज विकसित कर रहा हूं, तो मैं हर बार जब मैं अपने आवेदन के एक परिनियोजित संस्करण का परीक्षण करना चाहता हूं, तो मैं एक नए हेल्म चार्ट को एक हेल्म रिपोजिटरी में पैकेज और अपलोड नहीं करना चाहता हूं। लेकिन मैं अभी भी प्रत्येक रिलीज के लिए तैनात संस्करण या प्रतिबद्ध आईडी देखना चाहता हूं, यही कारण है कि हम विकास रिलीज के लिए ऐपवर्सन को ओवरराइड करना चाहते हैं लेकिन शायद उत्पादन रिलीज नहीं।

हालांकि मैं जो कह रहा हूं वह यह है कि जिन परिस्थितियों में आप ऐप वर्जन के लिए एक अलग संस्करण चाहते हैं, जो कि चार्ट में है। यदि यह विकास स्तर का संस्करण नहीं था तो आप केवल चार्ट.yaml के अंदर ऐप संस्करण संख्या रख सकते थे और चार्ट के अंतिम उपयोगकर्ता उस ऐप संस्करण को डिफ़ॉल्ट ऐप संस्करण के रूप में उपयोग कर सकते थे।

यही कारण है कि हेलम चार्ट का कार्यान्वयन और उपयोग कैसे किया जाता है, इस पर हेलम को बिना किसी राय के रहना चाहिए।
हेल्म को स्थानीय और उससे आगे की तैनाती रणनीति की परवाह नहीं करनी चाहिए, जो कि टीम/प्रोजेक्ट के वर्कफ़्लो के लिए पता लगाने के लिए है। लेकिन इस विशेषता यह है कि अनुरोध किया जा रहा है से digressing है, के लिए अनुमति .Chart.AppVersion स्थापित / अपडेट किए बिना उन्नयन के समय में स्थापित किया जाना Chart.yaml

जब भी मैं अपने आवेदन के एक परिनियोजित संस्करण का परीक्षण करना चाहता हूं, तो मैं हर बार एक हेल्म रिपोजिटरी में एक नया हेलम चार्ट पैकेज और अपलोड नहीं करना चाहता हूं

मैं जो कह सकता हूं उससे पहले से ही इस पर कोई राय नहीं है, क्योंकि इसके पास helm upgrade कॉल करते समय ठीक ऐसा करने का साधन है।

चार्ट तर्क या तो हो सकता है: एक चार्ट संदर्भ ('example/mariadb'), एक चार्ट निर्देशिका के लिए एक पथ, एक पैकेज्ड चार्ट, या एक पूरी तरह से योग्य URL। ~ https://helm.sh/docs/helm/helm_upgrad/

@woodcockjosh कई उपयोग के मामले हैं और जैसा कि @rcampbel कहते हैं कि पतवार को इस पर बिना किसी राय के रहना चाहिए और लोगों को अपने तरीके से काम करने देना चाहिए।
अगर मैं "चार्ट में प्रकाशित होना चाहिए" तर्क (चरम तक) का पालन करता हूं तो हेलम के पास --set या --values , -f झंडा क्यों है और उस मामले के लिए क्यों है एक values.yaml फ़ाइल बिल्कुल? फ़्लैग द्वारा प्रदान की गई सभी चीज़ें परिनियोजन समय ओवरराइड हैं जो प्रकाशित चार्ट में होनी चाहिए थीं। मैं जानता हूँ कि यह एक चार्ट में रहस्य डाल करने के लिए बुरा है, लेकिन यह है कि अगर एकमात्र कारण था तो आर्ग होना चाहिए --secrets बजाय --values ।

मेरी स्थिति में हम एक ही चार्ट का उपयोग करने वाले कई ऐप्स को तैनात करते हैं। इन ऐप्स को CI/CD पद्धति का उपयोग करके परिवेशों के माध्यम से प्रचारित किया जाता है। ऐप विशिष्ट और पर्यावरण विशिष्ट कॉन्फ़िगरेशन (आमतौर पर प्रवेश और डेटा स्रोत विवरण) प्रदान करने के लिए ऐप्स --values ध्वज का उपयोग करते हैं। यदि मैं प्रत्येक परिवेश के लिए प्रत्येक ऐप संस्करण के लिए एक नया चार्ट प्रकाशित कर रहा होता तो मैं प्रति सप्ताह सैकड़ों से हजारों चार्ट संस्करण बना रहा होता। अधिकांश उदाहरणों में केवल अंतर ही ऐप संस्करण होगा। फिर मुझे चार्ट संस्करण को टक्कर देने के लिए मजबूर होना पड़ता है। मेरे लिए इस पूरे पैराग्राफ द्वारा शुरू की गई आवश्यकताएं, जबकि एक चीज दूसरे को ट्रिगर करने के साथ तार्किक है, पागल है।

जैसा कि मौजूदा .Chart.appVersion हमारे लिए काम नहीं कर रहा है, हम एक स्थिर .Chart.appVersion पर वापस आ गए हैं और .Values.image.tag का उपयोग कर रहे हैं (यह उस बहस को फिर से खोलने का निमंत्रण नहीं है)

मुझे यकीन था कि appVersion दस्तावेज़ीकरण पढ़ने के बाद आवेदन संस्करण के बारे में जाने का तरीका था, जब तक कि यह सभी वैध उपयोग मामलों को पढ़ने तक नहीं।

चार्ट पैकेज के उपयोगकर्ताओं के लिए image.tag को टक्कर देना आसान है, इसका तात्पर्य केवल मूल्यों को संशोधित करना है, चार्ट कहीं और रह सकता है। लेकिन का उपयोग करके image.tag जब कर आप पैकेज संस्करण के बारे में जानकारी नहीं मिलता है helm history <release>

मैंने यह भी देखा है कि helm package <chart> Chart.version साथ एक टैर फ़ाइल जेनरेट करेगा। यदि आप केवल अपने ऐप का एक नया संस्करण वितरित करना चाहते हैं, और appVersion का उपयोग किया जाता है, तो आपसे version टकराने की उम्मीद है, अन्यथा आप पिछली फ़ाइल को अधिलेखित कर देंगे। यदि appVersion और version अलग-अलग हैं, तो version लिए स्वचालित टूल के साथ सही सेवर बम्प की गणना करना कठिन है (मान लीजिए कि appVersion कमिट संदेशों के आधार पर टकरा गया है) ) आप लोग इससे कैसे निपटते हैं?

हमें बस कुछ ऐसा चाहिए जो एक वास्तविक ऐप संस्करण हो जिसे हम परिनियोजित चार्ट को सूचीबद्ध करते समय देख सकते हैं।

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

बस, कृपया हमें यह तय करने दें कि हम इस पैरामीटर का उपयोग कैसे करेंगे। यदि कुछ तकनीकी कारणों से यह संभव नहीं है तो कृपया हमें बताएं कि ऐसा क्यों है।

जैसा कि 8194 में उल्लेख किया गया है, मैं "sed" का उपयोग नहीं करना पसंद करता/करती हूं
जब तक यह हल नहीं हो जाता (या नहीं) यहां बताया गया है कि मैंने इसे अपने सीआई/सीडी (गिटलैब) में कैसे हल किया:

ऐप-संस्करण के साथ चार्ट को पैकेज करें, फिर उसे परिनियोजित करें।
मुझे पता है कि चार्ट संस्करण ऐप वर्जन के समान नहीं है, लेकिन हमारे मामले में यह वर्कअराउंड के रूप में ठीक है।

इसके अलावा हेल्म रेपो पर अपलोड करने की कोई आवश्यकता नहीं है, लेकिन परिणामी सीआई कलाकृतियों (chart.tgz) का उपयोग करना संभव है।

तो अगर पहले पैकेजिंग कोई मुद्दा नहीं है, और आपको आज के लिए कामकाज की ज़रूरत

deploy:
  image: alpine/helm:3.2.4
  stage: deploy
  environment:
    name: ${ENV}
  script:
    - helm package --app-version=${CI_COMMIT_TAG} --version=${CI_COMMIT_TAG} ${NAMESPACE}
    -  | 
       helm upgrade -i --wait ${CI_PROJECT_NAME} ./${NAMESPACE}-${CI_COMMIT_TAG}.tgz \
       --set image.repository="${CI_REGISTRY_IMAGE}" \
       --set image.tag="${CI_COMMIT_TAG}" 
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

आउटपुट में अब मेरे पास संस्करण उपलब्ध हैं।

 $ helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
 REVISION   UPDATED                     STATUS      CHART       APP VERSION DESCRIPTION                                                                                                         
 45         Sun Aug  9 15:40:42 2020    superseded  prd-0.1.0   1.16.0      Upgrade complete                                                     
 46         Mon Aug 10 11:38:56 2020    superseded  prd-v0.2.25 v0.2.25     Upgrade complete                                                     
 47         Mon Aug 10 11:55:41 2020    deployed    prd-v0.2.26 v0.2.26     Upgrade complete                                                     
 Job succeeded

@हैमारी
स्निपेट के लिए धन्यवाद, जो कोई भी देख रहा है उसके लिए इस ट्रेड में पहले एक और उदाहरण है https://github.com/helm/helm/issues/8194#issuecomment -635879040 जो समान परिणाम प्राप्त करता है।

हालाँकि यह मुद्दा यह है कि चार्ट को फिर से तैयार करना अवांछनीय है और पतवार के रखवाले उस राय और काम करने के तरीके को मजबूर कर रहे हैं। यह अनुरोध है कि पतवार को कम राय दी जाए और पतवार को इस तरह से इस्तेमाल करने की अनुमति दी जाए जो समुदाय के अन्य हिस्सों के लिए बेहतर हो।
इस अंक और https://github.com/helm/helm/issues/3555 ने .Chart.version और .Chart.appVersion बीच के अंतरों का पता लगाया है, विशेष रूप से अधिकांश सार्वजनिक चार्ट appVersion को कैसे जोड़ते हैं कंटेनर टैग जिसने चार्ट संस्करण को केवल इसलिए बदलने के लिए मजबूर किया है क्योंकि ऐप का एक नया संस्करण जारी किया गया है। हालांकि अधिकांश सार्वजनिक चार्टों के लिए यह एक अच्छी धारणा हो सकती है, लेकिन यह धारणा बड़ी संख्या में निजी चार्टों के लिए मान्य नहीं है। इसलिए पतवार के अनुरक्षकों से यह अनुरोध कि समुदाय पर उस दृष्टिकोण को थोपना बंद करें।

ps आपका कोड स्निपेट एक चार्ट संस्करण प्रति रिलीज़ / प्रति परिवेश को दर्शाता है जो तब image.repository और image.tag सेट करने की आवश्यकता को हटा देगा। मैं उस स्थिति में चार्ट को प्रकाशित करने के लिए एक कदम की अपेक्षा करता हूं जब आपको फिर से तैनात करने की आवश्यकता होती है https://github.com/helm/helm/issues/8194#issuecomment -658715462 ऊपर देखें जो उस खरगोश की खोज करता है छेद

@हैमारी
स्निपेट के लिए धन्यवाद, जो कोई देख रहा है, उसके लिए इस ट्रेड #8194 (टिप्पणी) में पहले एक और उदाहरण है जो समान परिणाम प्राप्त करता है।

हालाँकि यह मुद्दा यह है कि चार्ट को फिर से तैयार करना अवांछनीय है और पतवार के रखवाले उस राय और काम करने के तरीके को मजबूर कर रहे हैं। यह अनुरोध है कि पतवार को कम राय दी जाए और पतवार को इस तरह से इस्तेमाल करने की अनुमति दी जाए जो समुदाय के अन्य हिस्सों के लिए बेहतर हो।
इस अंक और #3555 ने .Chart.version और .Chart.appVersion बीच के अंतरों का पता लगाया है, विशेष रूप से कैसे अधिकांश सार्वजनिक चार्ट कंटेनर टैग से appVersion को जोड़ते हैं जिसने चार्ट संस्करण को केवल इसलिए बदलने के लिए मजबूर किया है क्योंकि एक ऐप का एक नया संस्करण जारी किया गया है। हालांकि अधिकांश सार्वजनिक चार्टों के लिए यह एक अच्छी धारणा हो सकती है, लेकिन यह धारणा बड़ी संख्या में निजी चार्टों के लिए मान्य नहीं है। इसलिए पतवार के अनुरक्षकों से यह अनुरोध कि समुदाय पर उस दृष्टिकोण को थोपना बंद करें।

ps आपका कोड स्निपेट एक चार्ट संस्करण प्रति रिलीज़ / प्रति परिवेश को दर्शाता है जो तब image.repository और image.tag सेट करने की आवश्यकता को हटा देगा। मैं उस स्थिति में चार्ट को प्रकाशित करने के लिए रीपैकेजिंग के बाद एक कदम की उम्मीद करता हूं, जिस स्थिति में आपको फिर से तैनात करने की आवश्यकता है # 8194 (टिप्पणी) देखें जो उस खरगोश के छेद की पड़ताल करता है

@timothyclarke जानकारी के लिए धन्यवाद।

1. यह सबसे अच्छा अभ्यास नहीं है बल्कि _"चार्ट.yaml संपादित किए बिना इंस्टॉल या अपग्रेड के दौरान .Chart.AppVersion सेटिंग का एक साधन प्रदान करें" के लिए एक समाधान है।
2. चार्ट को रिपॉजिटरी में धकेलने की कोई आवश्यकता नहीं है, यह सीधे Gitlab से कई k8s क्लस्टर के साथ काम करता है।
3. यह वह सब प्रदान करता है जो मुझे रिलीज़ करने के लिए चाहिए:

image.repository और image.tag वैसे भी पाइपलाइन पर ठीक उसी तरह सेट किए जाते हैं,
तो पैकेजिंग लाइन के बिना भी, गिटलैब से हेल्म का उपयोग करने का यह तरीका है।

CI_COMMIT_TAG वैरिएबल में चलने वाली पाइपलाइन का वर्तमान रिलीज़ टैग होता है।
इसलिए हम हमेशा एक क्लिक के साथ सीआई पाइपलाइन से सीधे पिछले संस्करण में वापस आ सकते हैं।

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

इंस्टॉल के दौरान ऐपवर्सन सेट करने के विकल्प की अनुपस्थिति (और इसलिए इसे हमेशा एक ही मान पर सेट करना) हमारी परिनियोजन प्रक्रिया में एक बड़ी कमी है। यह वास्तव में कष्टप्रद है कि हमारे उपयोगकर्ता "हेल्म सूची" करके एप्लिकेशन संस्करण नहीं देख सकते हैं

"helm install ... --app-version v1.2.3" जैसी किसी चीज़ का उपयोग करने की क्षमता होने से हमारे मामले में Helm का उपयोग करने में बहुत अधिक मूल्य जुड़ जाएगा।

मेरा प्रस्ताव appVersion को पदावनत करना होगा और helm list या helm history <name> करते समय chart version और container tag सूचीबद्ध करना होगा।
हेल्म को कंटेनर के अंदर वास्तविक ऐप संस्करण प्रदान करने का प्रयास नहीं करना चाहिए, उसे यह प्रदान करना चाहिए कि उसके पास क्या है, टैग और चार्ट संस्करण, यहां कुछ उदाहरण हैं:

| चार्ट | कंटेनर टैग |
| ----- | ----- |
| 0.1.0 | 0.3.0 |
| 0.1.0 | 0.4.0 |

उपरोक्त उदाहरण में हम अनुमान लगा सकते हैं कि चार्ट का विभिन्न टैग के लिए पुन: उपयोग किया जा रहा है

| चार्ट | कंटेनर टैग |
| ----- | ----- |
| 0.3.0 | 0.3.0 |
| 0.4.0 | 0.4.0 |

उपरोक्त उदाहरण में हम संभावित रूप से अनुमान लगा सकते हैं कि चार्ट टैग के समान संस्करण साझा करता है।

appVersion का मुख्य पहलू यह प्रतीत होता है कि इसके लिए पैकेज को फिर से प्रकाशित करने की आवश्यकता है, भले ही चार्ट नहीं बदला हो, लेकिन कंटेनर के अंदर कोड है। इस बीच, कंटेनर का टैग values.yaml माध्यम से प्रदान किया जा सकता है और इसे पुनर्प्रकाशित करने की आवश्यकता नहीं है।

वैकल्पिक

मुझे लगता है कि helm list या helm history करते समय कंटेनर टैग को सूचीबद्ध करना सबसे आसान होगा, लेकिन यह अजीब होगा कि appVersion चारों ओर लटका हुआ हो। यह कम से कम, कुछ अतिरिक्त जानकारी देगा, और लोग appVersion को अनदेखा कर सकते हैं।

एक अन्य समाधान, appVersion को पदावनत करने के बजाय, इसे values.yaml ले जाया जा सकता है, इस तरह इसे चार्ट से अलग कर दिया जाएगा, जिससे कई पुनर्प्रकाशन को रोका जा सकेगा।

विचार?

@Woile क्या होगा यदि आपके ऐप में 1 से अधिक कंटेनर हैं?

@Woile क्या होगा यदि आपके ऐप में 1 से अधिक कंटेनर हैं?

आप सही हैं, उस उपयोग के मामले को भी देखते हुए (क्षमा करें, मैं अपने उपयोग के मामलों के बारे में सोच रहा था), मुझे लगता है कि appVersion को values.yaml जाने से स्थिति में सुधार होगा।

• helm list और helm history समान रह सकते हैं
• आपके पास एक से अधिक कंटेनर हो सकते हैं
• आपको हर बार फिर से प्रकाशित करने की आवश्यकता नहीं है, लेकिन यदि आप Chart और appVersion को सिंक में रखना चाहते हैं तो आप कर सकते हैं।

मुझे किसकी याद आ रही है?

मेरी प्राथमिकता ऐपवर्सन को स्पष्ट रूप से नियंत्रित करने की अनुमति देगी। यह कंटेनर टैग के बराबर हो सकता है, या इसे एक अलग मान पर सेट करने की आवश्यकता हो सकती है (उदाहरण के लिए मेरी इंस्टॉल स्क्रिप्ट किसी दिए गए कंटेनर रिपोजिटरी/नेमस्पेस/टैग की तलाश करती है और फिर उन्हें उपयोगकर्ता के अनुकूल में बदलने के लिए रेगेक्स लागू करती है ऐप संस्करण प्रदर्शित करने के लिए प्रारूप)

@woodcockjosh @woile
मेरा $0.02। appVersion की अवधारणा helm ls के दृष्टिकोण से अच्छी है। कार्यान्वयन वह मुद्दा है जिसे मैं सही देखना चाहता हूं। appVersion में एकाधिक टैग/संस्करण होना ठीक होना चाहिए जैसे appVersion: nginx-1.16.0-php-7.5

मैं ध्यान देता हूं कि हेलम 3.2.4 में {{ .Values.image.tag | default .Chart.AppVersion }} इसलिए उस तरह के डिस्कनेक्ट की अनुमति देता है

इंस्टॉल/अपग्रेड के दौरान ऐप वर्जन को चुनने की क्षमता सबसे पसंदीदा तरीका होगा। जब भी ऐप संस्करण बदलता है तो चार्ट संस्करण को उछालने का कोई मतलब नहीं है क्योंकि चार्ट स्वयं नहीं बदला गया है। वर्जनिंग की रैखिक प्रगति भी हमेशा लागू नहीं होती है - विशेष रूप से बहु कंटेनर अनुप्रयोगों के लिए कंटेनर संस्करणों के विभिन्न संयोजनों के साथ विभिन्न वातावरणों में तैनात किया जा रहा है। एक ही ऐप वर्जन और चार्ट वर्जन का उपयोग करने का सुझाव भी खराब है क्योंकि यह ऐप वर्जन को सेमवर संगत होने के लिए मजबूर करता है। semVer वर्जनिंग की पवित्र कब्र नहीं है और ऐप वर्जन को किसी भी वर्जनिंग स्कीम का उपयोग करने के लिए स्वतंत्र होना चाहिए जो कि एप्लिकेशन के लिए सबसे उपयुक्त हो।

@bacongobbler क्या इस टिप्पणी का मतलब यह है कि पतवार इस तरह के झंडे को लागू करने की योजना बना रही है?

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

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

मेरा निष्कर्ष

• एक अम्ब्रेला चार्ट को कई चार्ट (निर्भरता) के एक समूह के रूप में माना जा सकता है जो उचित जीवनचक्र का अनुसरण करता है
• एक अम्ब्रेला चार्ट एकमात्र ऐसा मामला है जहां ऐप वर्जन सीधे इस्तेमाल की गई छवि से जुड़ा नहीं है।
• एक एप्लिकेशन हमेशा एक चार्ट प्रदान करता है जहां कई मामलों में ऐप-संस्करण = छवि टैग (इसलिए एप्लिकेशन कोड में ट्रांज़िटिविटी द्वारा)
• एप्लिकेशन कोड और चार्ट कोड के बीच स्रोत अलगाव केवल डॉकर छवि और चार्ट के बीच अनुपालन पर कुछ कठिनाइयों का परिचय देता है।
• "स्प्रिंग-बूट चार्ट" जैसे साझा चार्ट को हमेशा एप्लिकेशन चार्ट में एक निर्भरता के रूप में उपयोग करने की आवश्यकता होती है (भले ही आपका एप्लिकेशन केवल इस निर्भरता से बना हो) ... आप एक साझा चार्ट नहीं बल्कि एक एप्लिकेशन को तैनात करते हैं!

मेरी वर्तमान पसंद

• एक साझा चार्ट केवल इसके संस्करण के साथ एक चार्ट तैयार करता है और ऐप-संस्करण हमेशा खाली होता है (कभी उपयोग नहीं किया जाता है)
• एक साझा चार्ट का उपयोग कभी भी परिनियोजन करने के लिए सीधे नहीं किया जाता है।
• एक एप्लिकेशन (घटक) चार्ट हमेशा उचित चार्ट का उत्पादन करता है, जहां चार्ट संस्करण = ऐप-संस्करण = छवि टैग
• एक अम्ब्रेला चार्ट फॉलो उचित जीवन शैली है जहां चार्ट संस्करण ऐप-संस्करण का प्रतिनिधित्व करता है

प्रश्न / विचार

मुझे नहीं पता कि ऐप-संस्करण क्यों पेश किया जाना चाहिए (शायद साझा चार्ट के खराब उपयोग को कवर करने के लिए)।
मुझे लगता है कि इसे हटाना और sed या yq जैसे वर्कअराउंड का उपयोग किए बिना पैकेज चरण में छवि टैग सेट करने की क्षमता पेश करना एक अच्छा विचार हो सकता है।

शायद एक बहुत लंबी पोस्ट लेकिन मुझे कुछ फीडबैक चाहिए

@grazius
आपकी पोस्ट के बारे में मेरी समझ यह है कि --set , -f और --values झंडे खराब हैं और इनका कभी भी उपयोग नहीं किया जाना चाहिए। सभी परिनियोजन अपरिवर्तनीय हैं और उन्हें एक चार्ट में प्रस्तुत किया जाना चाहिए, भले ही वह चार्ट values.yaml से थोड़ा अधिक हो और एक निर्भरता के रूप में छाता चार्ट। यह चार्ट (एप्लिकेशन) निर्माण समय पर प्रस्तुत किया जाना चाहिए और चार्ट रेपो में प्रकाशित किया जाना चाहिए

उपरोक्त स्थिति में आप रहस्य या इसी तरह की संवेदनशील जानकारी कहाँ संग्रहीत कर रहे हैं? हर जगह जहां मैंने काम किया है, उन्हें --values फ़ाइल के माध्यम से फीड किया गया है

कुछ संदर्भों के लिए मेरी तैनाती में प्रभावी रूप से 3 तत्व होते हैं जिन्हें स्वतंत्र रूप से संस्करणित किया जाता है

• चार्ट
• आवेदन
• (पर्यावरण) कॉन्फ़िगरेशन मान

अगर मैं उनमें से किसी एक को बदल दूं तो मुझे दूसरे के पुनर्निर्माण के लिए मजबूर नहीं होना चाहिए। मैं आम तौर पर एकाधिक परिवेशों का उपयोग कर रहा हूं ताकि अनुप्रयोगों के _live_ जाने से पहले उनका परीक्षण किया जा सके। जैसे कि एक परिनियोजन chart-v1.0 application_build-50 config_non-prod-v1.3 साथ env कॉन्फिग फाइलों को gpg एन्क्रिप्टेड संग्रहित करना चाहेगा।
मेरा सीआई प्लेटफॉर्म परीक्षण के माध्यम से उत्पादन के माध्यम से स्रोत से निर्माण प्रवाह के रूप में एप्लिकेशन निर्माण, तैनाती, प्रचार का प्रबंधन कर रहा है। अगर हमें एप्लिकेशन के ऐतिहासिक संस्करण को फिर से तैनात करने की आवश्यकता है तो हम उन नौकरियों को फिर से चलाएंगे।

प्रश्न: हमें यह बताने के लिए चार्ट रिपॉजिटरी का उपयोग करने के लिए क्यों मजबूर होना चाहिए कि मेरा सीआई प्लेटफॉर्म बॉक्स से बाहर है? हमें इसे कभी भी हाथ से इंस्टॉल नहीं करना चाहिए

@timothyclarke बस रहस्य प्लगइन का उपयोग करना सुनिश्चित करें ताकि आप एन्क्रिप्टेड मान फ़ाइलों का उपयोग कर सकें

@timothyclarke हैलो, इस पहली प्रतिक्रिया के लिए धन्यवाद;)

• रिपोजिटरी का लाभ (जैसे, पीपीआई, मेवेन सेंट्रल, विकास के लिए डॉकर रजिस्ट्रियां) यह है कि जेनरेट किए गए आर्टिफैक्ट को अपरिवर्तनीय आश्वासन के साथ साझा और प्रकाशित किया जा सकता है (हेल्म के लिए यह एक टीजीजेड है)।
• पर्यावरण के मूल्यों के लिए (यह एक अन्य विषय है) उन्हें संग्रहीत किया जा सकता है जहां आप चाहते हैं (एससीएम रेपो, रहस्यों के लिए हैशिकॉर्प जैसे समर्पित समाधान, नेटपोल के लिए इल्यूमियो, आदि ...)

एक चार्ट डिफ़ॉल्ट मान प्रदान करता है। yaml (प्रत्येक चार्ट संस्करण के लिए अपरिवर्तनीय) जो चार्ट उपभोक्ताओं द्वारा उपयोग (या ओवरराइड) किया जा सकता है।
Chart.yaml के लिए यह चार्ट का एक अपरिवर्तनीय हिस्सा भी है ... और इसमें app-version शामिल है।

आपके मामले में, ऐप-संस्करण के लिए हेलम सूची में क्या प्रदर्शित होता है? 50?
यदि हां, तो आपने अपनी पाइपलाइन में एप्लिकेशन संस्करण को चार्ट ऐप-संस्करण में कैसे रखा?

@grazius

एक चार्ट डिफ़ॉल्ट मान प्रदान करता है। yaml (प्रत्येक चार्ट संस्करण के लिए अपरिवर्तनीय) जो चार्ट उपभोक्ताओं द्वारा उपयोग (या ओवरराइड) किया जा सकता है।
Chart.yaml के लिए यह चार्ट का एक अपरिवर्तनीय हिस्सा भी है ... और ऐप-संस्करण इसमें शामिल है।

हो सकता है कि मैं गलत समझ रहा हूं कि आप यहां क्या कह रहे हैं, लेकिन इससे यह सवाल उठता है कि ऐप-संस्करण भी क्यों है यदि यह प्रत्येक चार्ट संस्करण के लिए अपरिवर्तनीय है? तो प्रत्येक एप्लिकेशन संस्करण परिवर्तन के लिए चार्ट संस्करण में भी टक्कर होनी चाहिए, भले ही चार्ट में कोई अन्य परिवर्तन नहीं किया गया हो? यदि ऐसा है तो चार्ट संस्करण या ऐप संस्करण भी क्यों है?

मैं यह भी चला जाता है के खिलाफ क्या अनुरोध किया जा रहा है, मेरा मानना है कि "स्थापित करने या संपादन Chart.yaml बिना उन्नयन के दौरान .Chart.AppVersion स्थापित करने का एक साधन प्रदान करें" लगता है क्या @timothyclarke इस चैट चीजों को रकम काफी अच्छा में पहले कहा: https: / /github.com/helm/helm/issues/8194#issuecomment -671331311

मुझे लगता है कि ध्यान में रखने वाली एक और महत्वपूर्ण बात यह है कि उपयोग किए जा रहे चार्ट पर हर किसी का नियंत्रण नहीं होता है, लेकिन तैनाती के समय चार्ट में उपयोग की जाने वाली छवि और अन्य मूल्यों को पारित करने की क्षमता हो सकती है। उस स्थिति में आप ऐप-संस्करण को अपडेट करने का सुझाव कैसे देंगे जो तैनात किया गया है?

यहाँ वही मुद्दा!
के उपयोग को ध्यान में रखते --description एक समाधान के रूप झंडा किसी तरह से आवेदन के संस्करण को दिखाने के लिए प्रदान करने के लिए helm list 🤔

जब आप छाता चार्ट बनाते हैं तो ऐप-संस्करण वास्तव में आवश्यक होता है। घटक चार्ट के लिए, चार्ट संस्करण और ऐप-संस्करण को अलग-अलग विकसित करने की रुचि बहुत कम है, मुझे लगता है।

शायद मुख्य समस्या यह है कि चार्ट.यमल का प्रकार पर्याप्त सटीक नहीं है? छाता, साझा या एप्लिकेशन चार्ट में अंतर करने का कोई तरीका नहीं है

@grazius यह काफी राय वाली प्रतिक्रिया है।
हालांकि यह कई ओपन सोर्स प्रोजेक्ट्स के लिए लागू हो सकता है, लेकिन यह कई क्लोज्ड सोर्स बिल्ड पर लागू नहीं होता है। कृपया सभी विभिन्न कथनों और उपयोग के मामलों सहित इस थ्रेड की फिर से समीक्षा करें क्योंकि यह अनुरोध चार्ट की विशिष्टता से .Chart.AppVersion को हटाने का अनुरोध नहीं है। यह APP VERSION के आउटपुट से helm ls को छिपाने का अनुरोध भी नहीं है।
यह थ्रेड उस समय Chart.AppVersion कॉन्फ़िगर करने योग्य बनाने का अनुरोध है जब चार्ट का उपयोग किया जाता है (चार्ट को पुनर्निर्माण या अन्यथा बदलने के बिना) ताकि APP VERSION फ़ील्ड helm ls भ्रामक नहीं है।

यह खड़ा है के रूप में मैं इस समय का तर्क था कि APP VERSION में एक ज़रूरत से ज़्यादा क्षेत्र है helm ls और कितने करीब से की वजह से क्रम आदेशों को दिखाई नहीं होना चाहिए .Chart.AppVersion से जुड़ा हुआ है .Chart.Version । helm inspect chart --version <.Chart.Version> <.Chart.Name> समान जानकारी प्रदान करता है।
मैं इसे कंटेनर टैग के रूप में उपयोग करने के लिए .Chart.AppVersion के उपयोग में भी विस्तारित करूंगा क्योंकि वे सभी अलग-अलग चीजें हैं जिन्हें वैध कारणों से स्वतंत्र रूप से संस्करणित किया जा सकता है, लेकिन वर्तमान में एक ही चीज़ में शूहोर्न किया जाता है।
मैंने इस अनुरोध के बाहर उस संबंध पर अपनी राय रखने की कोशिश की है क्योंकि परियोजनाओं के इस तरह के संबंध के लिए पूरी तरह से वैध कारण हो सकते हैं। पतवार का उपयोग करने वाले प्रत्येक व्यक्ति पर समान प्रक्रिया को लागू न करके हम पतवार को एक बेहतर और अधिक समावेशी उपकरण बनाते हैं।
मुझे नहीं लगता कि ये अनुरोधित परिवर्तन दूसरों पर उनके उपयोग को कम करते हैं या उनके उपयोग को मजबूर करते हैं।

@bacongobbler क्या आप कृपया इस पर टिप्पणी कर सकते हैं? इसकी अत्यधिक अनुरोधित विशेषता

इसकी अत्यधिक अनुरोधित विशेषता

नमस्ते, @jasondamour - आपकी रुचि के लिए धन्यवाद! दो अच्छे विकल्प: एक हेल्म प्लगइन बनाना और एक HIP लिखना।

नमस्ते, शायद सबसे अच्छा समाधान इंस्टॉल/अपग्रेड कमांड के लिए रिलीज-ऐप-संस्करण तर्क प्रदान करना है कि यदि हम एक हेलम सूची करते हैं तो ऐप-संस्करण डिस्प्ले को ओवरराइड करते हैं।