Auto: कस्टम बम्प प्रतिबद्ध संदेश

मैं कोई टक्कर नहीं करना पसंद कर सकता हूं (जैसे semantic-release यह करता है):

{
  "skipBumpCommit": true
}

बंप कमिट्स अक्षम होने के साथ, नवीनतम एनपीएम संस्करण सत्य का स्रोत है (या शायद यह पहले से ही इस तरह से काम करता है?) और package.json में "संस्करण" फ़ील्ड को 0.0.0-development या इसी तरह सेट किया जा सकता है।

स्किप सीआई ट्रैविस पर अलग है? इसके बिना आपके प्रतिबद्ध संदेशों में आप आसानी से एक पाश में पड़ सकते हैं

auto स्थानीय संस्करण और प्रकाशित संस्करण को देखने का उपयोग करेगा और npm त्रुटियों से बचने के लिए उच्चतर का चयन करेगा। क्या यह पर्याप्त है?

स्किप सीआई ट्रैविस पर अलग है? इसके बिना आपके प्रतिबद्ध संदेशों में आप आसानी से एक पाश में पड़ सकते हैं

मुझे वास्तव में यकीन नहीं है। यदि प्रतिबद्ध शीर्षलेख में इसकी आवश्यकता है, तो ऐसा ही हो। मैं

auto स्थानीय संस्करण और प्रकाशित संस्करण को देखने का उपयोग करेगा और npm त्रुटियों से बचने के लिए उच्चतर का चयन करेगा। क्या यह पर्याप्त है?

क्या सचमे? अच्छा। क्या उस मामले में कोई बम्प कमिट नहीं बनाया गया है?

नहीं, उस स्थिति में हम प्रकाशित संस्करण को टक्कर देते हैं क्योंकि आप पुराने संस्करण पर प्रकाशित कर सकते हैं।

मुझे यह देखने में परेशानी हो रही है कि skipBumpCommit कैसे काम करेगा या अंतिम परिणाम कैसा दिखेगा। shipit चलाने के लिए आपको संस्करण को किसी तरह से बदलना होगा, इसलिए मैं नहीं देख सकता कि आप उस प्रतिबद्धता से कैसे बाहर निकल सकते हैं।

क्या आप के बारे में सोच है shipit लंघन प्रतिबद्ध टक्कर जब में संस्करण package.json की तरह कुछ है 0.0.0-development ?

1. पैकेज 0.0.0-विकास पर शुरू होता है

2. आप version चलाते हैं, यह पीआर के आधार पर टक्कर देता है, यह कुछ भी देता है (पैच, नाबालिग, प्रमुख) - मान लें कि यह पैच है

3. चैंज निर्माण - (0.0.0-विकास => 0.0.0)। लेकिन आप नहीं चाहते कि ऐसा हो? इसके बजाय '0.0.0-विकास' चैंज शीर्षक के अंतर्गत जोड़ें?

4. हुक समय प्रकाशित करें - यह 0.0.0-विकास => 0.0.0 और प्रकाशित होगा। लेकिन आप चाहते हैं कि development का पता लगाया जाए और सभी को एक साथ प्रकाशित करना छोड़ दें

5. एक जीथब रिलीज़ करें - एक नई रिलीज़ बनाने के बजाय, पुराने को नए कमिट के साथ अपडेट करें

6. पैकेज 0.0.0-विकास तक रहता है ??? जबकि परिवर्तन जमा होते हैं

दो विकल्प यदि आप यही चाहते हैं:

1. बस auto shipit तब तक न चलाएँ जब तक आप रिलीज़ और प्रकाशन शुरू नहीं करना चाहते। अभी भी अपने पीआर में लेबल जोड़ें। जब आप तैयार हों तो अपनी सीआई प्रक्रिया में auto shipit जोड़ें और इसमें आपकी पहली रिलीज में सभी लेबल पीआर शामिल होंगे।

2. एक प्लगइन लिखें। यह व्यवहार बहुत ही अनोखा है और वास्तव में npm वर्जनिंग के तरीके के अनुरूप नहीं है। मुझे लगता है कि आप इस सामान को पूरा करने के लिए एक प्लगइन बना सकते हैं। हालाँकि मुझे आपके उपयोग के लिए शायद एक या दो हुक जोड़ने होंगे।

0.0.0-development संस्करण वाला पैकेज निम्नलिखित इंगित करता है:

• उच्चतम प्रकाशित एनपीएम संस्करण को "वर्तमान संस्करण" माना जाता है
• version में package.json को कभी नहीं बदला जाना चाहिए

जब एक नया एनपीएम संस्करण प्रकाशित किया जाना चाहिए, तो ऑटो को npm version $(auto version) का उपयोग करके "वर्तमान संस्करण" को बढ़ाना चाहिए।

चेंजलॉग एनपीएम से "वर्तमान संस्करण" का उपयोग करता है ( package.json बजाय)।

हमेशा की तरह, प्रत्येक NPM संस्करण के लिए एक नया Github रिलीज़ बनाया गया है।

क्या मैं काफी स्पष्ट हूं?

package.json में संस्करण कभी नहीं बदला जाना चाहिए

NPM में नए संस्करण प्रकाशित करने के लिए आपको इसे बदलना होगा। "वर्तमान संस्करण" को बढ़ाने और स्थानीय को कभी भी बदलने का एकमात्र तरीका यह नहीं होगा:

• इसे वर्तमान संस्करण (एनपीएम) में बदलें
• टक्कर करो
• इसे वापस बदलें
• लेकिन चूंकि यह टैग टक्कर का वर्तमान संस्करण होगा ???

मुझे पूरा यकीन है कि मैं आपके उपयोग के मामले को समझता हूं।

ए। जब आप एकाधिक पीआरएस पर एक सुविधा विकसित कर रहे हों तो आप संस्करणों का एक समूह प्रकाशित नहीं करना चाहते हैं
बी। एक बार एक नया संस्करण प्रकाशित होने के बाद आप सभी परिवर्तनों को शामिल करना चाहते हैं

मेरी नज़र में हम आपको ऐसा करने के दो तरीके पहले ही दे चुके हैं:

1. onlyPublishWithReleaseLabel । जब तक आप यह लेबल नहीं जोड़ते तब तक नए संस्करण नहीं बनाए जाते। तो आप लेबल के बिना किसी भी पीआर/कोड को VERSION-development

2. चूंकि आप बड़ी सुविधा के लिए पीआर को विलय कर रहे हैं, तब तक skip-release जब तक कि आप एक संस्करण के लिए तैयार न हों, फिर बस एक पीआर मर्ज करें। नई रिलीज़ में छोड़े गए सभी पीआर शामिल हैं। इस मामले में आप skip-release लेबल को जोड़कर देख सकते हैं कि यह दर्शाता है कि आपका संस्करण VERSION-development

यह आपके इच्छित व्यवहार से किस प्रकार भिन्न है?

ऐसा लगता है कि मैं नीचे उबल रहा हूं: आप रिलीज को छोड़ना शुरू करने के लिए अपने संस्करण में -development जोड़ना चाहते हैं और जब आप सभी परिवर्तनों को एक बार में रिलीज़ करने के लिए तैयार हों तो इसे हटा दें।

मेरे अंतिम वाक्य को पूरा करने के लिए आप शायद एक प्लगइन बना सकते हैं जो beforeShipit का उपयोग संस्करण में -development की उपस्थिति की जांच करने के लिए करता है और यदि यह मौजूद है तो एक त्रुटि फेंकता है। यह shipit को तब तक आगे बढ़ने से रोकेगा जब तक आप -development हटा नहीं देते।

इसके साथ एकमात्र समस्या यह है कि यह सीआई की नौकरी को भी विफल कर देगा।

दिलचस्प व्याख्या, लेकिन वह नहीं जो मेरा इरादा था। मैं

मैं मूल रूप से वर्णन कर रहा हूं कि semantic-release काम करता है।

मैंने _चाहिए कहा है " package.json में संस्करण केवल npm publish सफल होने के लिए अस्थायी रूप से बदला गया है" (" package.json में संस्करण को कभी भी बदला नहीं जाना चाहिए" के बजाय)। मैं वास्तव में बस इतना करने की कोशिश कर रहा हूं कि पूरी तरह से टक्कर से बचें। :)

ठीक है, तो आप जिस राज्य में समाप्त होंगे वह है:

रेपो: केवल कभी verison है 0.0.0-देव

npm: हर समय वास्तविक संस्करण होता है (यह वही है जो किसी भी चीज़ के लिए उपयोग किया जाता है)

सही?

कुछ वैसा

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

हाँ, अच्छा लग रहा है!

auto v4.0.0 यहाँ हम योग्य हैं। ऐसा लगता है कि मुझे publish हुक को विभाजित करना होगा। यह एक और प्लगइन होगा

यदि आप चाहें, तो आप इस सुविधा को अभी के लिए ऑटो में बेक कर सकते हैं, और publish हुक को विभाजित करने के लिए प्रतीक्षा करें जब तक कि किसी अन्य प्लगइन को भी इसकी आवश्यकता न हो। मैं

यह प्लगइन के माध्यम से अब #247 (सेवर क्षमता) के साथ संभव होना चाहिए। प्रतिबद्ध संदेश चीज़ के लिए कुछ कॉन्फ़िगरेशन परिवर्तनों की आवश्यकता होती है और वास्तव में आपको बहुत कुछ नहीं मिलता है। बंद हो रहा है लेकिन पीआर के लिए खुला है!