Auto: 1 रेपो में एकाधिक पैकेज प्रबंधक प्लगइन्स

इसके बारे में थोड़ा और सोचकर मैं शायद एक नया शीर्ष स्तरीय कॉन्फ़िगरेशन विकल्प पेश करने के लिए और अधिक समझ में आता हूं।

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

इसे पूरा करने के लिए मुझे लगता है कि हम कई चीजों पर shipit चलाने के लिए इटरेटर फ़ंक्शंस का उपयोग कर सकते हैं और समान मात्रा में कमिट्स उत्पन्न कर सकते हैं

पूर्व नवीनतम के लिए:

1. सभी एक ही समय में दौड़ें
2. चैंज करने से पहले उपज
3. एक ही बार में चैंज करें
4. संस्करण टकराए जाने तक उपज
5. यदि आवश्यक हो तो संस्करण प्रतिबद्ध करें
6. अंत तक चलाएं

इस सेटअप के साथ आप वास्तव में लर्न को एक साथ छोड़ सकते हैं

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

यदि package कोई कमिट मिलान नहीं किया जाता है तो कोई रिलीज़ नहीं की जाएगी। यह स्वतंत्र मोनोरेपो प्रबंधन को बहुत सरल तरीके से और बिना lerna । यदि आप एक निश्चित संस्करण चाहते हैं तो मोनोरेपो क्लासिक मार्ग पर जा रहा है।

इसकी एक और अच्छी विशेषता यह है कि आपके रेपो में अलग-अलग वर्जनिंग स्कीमों ( fixed और independent ) के साथ आपके पास दो leran प्रोजेक्ट हो सकते हैं।

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

इसका मतलब है कि आप एक रेपो में क्रोम-वेब-स्टोर प्लगइन एनपीएम प्लगइन का उपयोग कर सकते हैं।

मुझे लगता है कि आपका मतलब है कि आप एक ही प्रोजेक्ट में दोनों का उपयोग नहीं कर सकते हैं?

प्रत्येक प्लगइन वर्तमान में कमिट, टैग और पुश करता है। यह बहुत शोर पैदा करेगा। शायद उन गिट क्रियाओं को कोर में ले जाना होगा, इसलिए यह केवल एक बार होता है? हालाँकि आप प्रत्येक पैकेज के लिए अलग-अलग कमिट चाहते हैं।

हाइब्रिड दृष्टिकोण करना समझ में आता है। हो सकता है कि प्रत्येक प्लगइन प्रतिबद्ध हो, लेकिन हम केवल एक बार धक्का देते हैं?

मुझे सच में यकीन नहीं है कि दुनिया में टैग कैसे काम करेंगे जहां प्रत्येक फ़ोल्डर अपनी खुद की पैकेज्ड रिलीज है। क्या आप अपने द्वारा बनाए गए प्रत्येक संस्करण के लिए एक टैग बनाते हैं? क्या आप अंत में एक बनाते हैं?

इसके बारे में थोड़ा और सोचकर मैं शायद एक नया शीर्ष स्तरीय कॉन्फ़िगरेशन विकल्प पेश करने के लिए और अधिक समझ में आता हूं।

मुझे प्रति पैकेज रिलीज अनुभव को अनुकूलित करने में सक्षम होने का विचार पसंद है। docs पैकेज बनाम आपके लाइब्रेरी पैकेज के लिए परिनियोजित s3/gh-पृष्ठों को प्रबंधित करने में सक्षम होने के कुछ लाभ निश्चित रूप से देख सकते हैं।

एक से अधिक रिलीज पाइपलाइन में पैकेज को शामिल करना एक बात है। के मामले में क्या होता है:

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

क्या chrome-ext पैकेज npm _और_ webstore दोनों पर प्रकाशित होता है? या npm रिलीज जीत जाती है क्योंकि इसे पहले घोषित किया गया है?

मुझे सच में यकीन नहीं है कि दुनिया में टैग कैसे काम करेंगे जहां प्रत्येक फ़ोल्डर अपनी खुद की पैकेज्ड रिलीज है। क्या आप अपने द्वारा बनाए गए प्रत्येक संस्करण के लिए एक टैग बनाते हैं? क्या आप अंत में एक बनाते हैं?

मुझे लगता है कि हम लर्न के व्यवहार से मेल खा सकते हैं। एक कमिट पर बहुत सारे टैग। प्रत्येक टैग तब स्वयं की रिलीज़ बन जाता है

क्या chrome-ext पैकेज npm और वेबस्टोर दोनों पर प्रकाशित होता है? या एनपीएम रिलीज जीतता है क्योंकि इसे पहले घोषित किया गया है?

उस स्थिति में हाँ यह दोनों करने की कोशिश करेगा। लेकिन यह सिर्फ खराब कॉन्फ़िगरेशन है। आप इसे एक सुविधा के रूप में उपयोग कर सकते हैं और कह सकते हैं कि दो अलग-अलग रजिस्ट्रियों के लिए एक पैकेज प्रकाशित करें (उदा: npm और github पैकेज रजिस्ट्री)

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

यह दिलचस्प लगता है... और जटिल 😅

मैं आम तौर पर पता लगाने के साथ अत्यधिक स्मार्ट होने की कोशिश में कॉन्फ़िगरेशन के साथ हूं (क्योंकि यह अप्रत्याशित तरीकों से टूट सकता है और परीक्षण करना मुश्किल हो सकता है)।

मुझे लगता है कि मेरा पहला सवाल यह है कि इसकी डिफ़ॉल्ट स्थिति कैसी दिखती है। यदि आपके पास सिर्फ npm प्लगइन है, तो क्या इसके काम करने से पहले आपको कॉन्फ़िगरेशन जोड़ने की आवश्यकता है? दूसरों के साथ भी यही सवाल।

गिट इंटरैक्शन के लिए, ऐसा लगता है कि गिट इंटरैक्शन आम तौर पर प्लगइन पाइपलाइन का हिस्सा होना चाहिए। यदि किसी प्लगइन को कमिट करने की आवश्यकता है, तो उसे केवल कमिट-सक्षम हुक में टैप करने में सक्षम होना चाहिए। पुशिंग को केवल कोर में ही संभाला जाना चाहिए, हालांकि सीआई कैसे चलता है जैसी चीजों पर इसका प्रभाव पड़ता है।

यदि आपके पास सिर्फ एक npm प्लगइन है, तो क्या आपको इसके काम करने से पहले कॉन्फ़िगरेशन जोड़ने की आवश्यकता है?

कॉन्फ़िगरेशन जो आज काम करता है उसे packages दुनिया में काम करना चाहिए। तो कोई बदलाव की आवश्यकता नहीं है। अधिकांश ब्रेकिंग परिवर्तन नोड एपीआई पक्ष होंगे और सामान्य उपयोगकर्ताओं के लिए दृश्यमान नहीं होंगे।

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

मुझे यह विचार पसंद है। ऑटो के भीतर इस गिट इंटरैक्शन को औपचारिक बनाना शायद उपयोगी है। और अगर वे इस हुक का उपयोग नहीं करते हैं तो इसका मतलब है कि थोड़ा और शोर (उदा: एक अतिरिक्त प्रतिबद्धता और एक अतिरिक्त धक्का)

मैं यह भी सोच रहा था कि मोनोरेपो के साथ ऑटो का उपयोग कैसे करें और थोड़ा अलग दृष्टिकोण लेकर आया जो आपकी आवश्यकता के लिए काम कर सकता है।

मूल रूप से यदि आपके पास एक मोनोरेपो है तो आपके पास कई उप-निर्देशिकाएं हो सकती हैं जिनमें प्रत्येक की अपनी .autorc फ़ाइल होती है जो प्रत्येक उप प्रोजेक्ट की आवश्यकता वाले प्लगइन्स को सेट कर सकती है।

फिर आप प्रत्येक प्रोजेक्ट के लिए एक अलग प्रीफ़िक्स चुन सकते हैं ताकि ज़रूरत पड़ने पर प्रत्येक प्रोजेक्ट को अलग-अलग समय पर रिलीज़ किया जा सके। उदाहरण के लिए उप-प्रोजेक्ट sub-project/v1.4.5 रिलीज़ को sub-project2/v9.9.9 टैग मिलेगा

ऑटो तब प्रत्येक प्रोजेक्ट के लिए टैग प्राप्त करने और अपडेट करने के लिए git describe --tags --matches "sub-project1/*" जैसी किसी चीज़ का उपयोग कर सकता है।

सिर्फ एक विचार।

यह वास्तव में उस दृष्टिकोण के काफी करीब है जिसे मैं ले रहा हूं। मैंने
इस सप्ताह इस पर काम कर रहा है।

मुझे उस ध्वज को अब तक के कुछ आदेशों में जोड़ना पड़ा है (-मैच) और
यह काफी सुचारू रूप से चल रहा है।

मैं "पैकेज" फ़ील्ड दृष्टिकोण के साथ गया हूं और यह मूल रूप से सिर्फ और
"autorc" s . की सरणी

उपसर्ग प्राप्त करने के लिए मैंने नाम प्रदान करने के लिए प्लगइन्स के लिए एक हुक जोड़ा है। इस
अगर प्लगइन बहु पैकेज संगत है तो ऑटो को सिग्नल में भी मदद करेगा

बुधवार, 29 जनवरी, 2020 को रात 9:11 बजे एलेजांद्रो बैरिएंटोस <
सूचनाएं@github.com> ने लिखा:

मैं यह भी सोच रहा था कि मोनोरेपो के साथ ऑटो का उपयोग कैसे करें और इसके साथ आया
थोड़ा अलग दृष्टिकोण जो आपकी आवश्यकता के लिए काम कर सकता है।

मूल रूप से यदि आपके पास एक मोनोरेपो है तो आपके पास कई उप-निर्देशिकाएं हो सकती हैं
कि प्रत्येक की अपनी .autorc फ़ाइल है जो किसी भी प्लगइन्स को सेटअप कर सकती है
प्रत्येक उप परियोजना की आवश्यकता होगी।

फिर आप प्रत्येक प्रोजेक्ट के लिए एक अलग उपसर्ग रखना चुन सकते हैं ताकि
यदि आवश्यक हो तो प्रत्येक परियोजना को अलग-अलग समय पर जारी किया जा सकता है। उदाहरण के लिए a
उप-परियोजना1 के विमोचन को उप-परियोजना/v1.4.5 के साथ टैग किया जा सकता है और
किसी अन्य प्रोजेक्ट को उप-प्रोजेक्ट2/v9.9.9 टैग मिलेगा

ऑटो तब git वर्णन --tags --matches . जैसी किसी चीज़ का उपयोग कर सकता है
"उप-प्रोजेक्ट1/*" प्रत्येक प्रोजेक्ट के लिए तदनुसार टैग प्राप्त करने और अपडेट करने के लिए।

सिर्फ एक विचार।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने सूत्र को लिखा है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXGEK43VMVBW63LNMVW800GOZLOOR9 मुद्दा
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

वापस जा रहा हूं और इसे फिर से पढ़ रहा हूं, मैं वास्तव में बहुत उत्साहित हूं! कई टैग उपसर्ग w/पैकेज नाम वास्तव में अच्छा लगता है। साथ ही, मुझे वास्तव में packages फ़ील्ड पसंद है।

@hipsstersmoothie आज शिपिट के साथ 2 npm रजिस्ट्रियों को प्रकाशित करने का एक आसान तरीका है, जो आपने देखा है? या ऑटो में कुछ फीचर टॉगल करता है कि मेरे पास अभी एक अच्छा अवलोकन नहीं है।

@vincentbriglia एक प्लगइन होगा जो GitHub पैकेज के काम को प्रकाशित करता है? यह npm प्लगइन से बहुत अधिक गुल्लक बंद कर सकता है। next और latest रिलीज के लिए यह आसान होगा, कैनरी उतना समझ में नहीं आता है। विचार?

@hipsstersmoothie हमारे पास एक ऐसा मामला है जहां हम उसी पैकेज को NPM रजिस्ट्री और GHPR रजिस्ट्री में प्रकाशित करते हैं। यहाँ कारण यह है कि GHPR, भले ही इस रूप में विज्ञापित हो, प्रॉक्सी पैकेज सही ढंग से नहीं करता है। अंतर्निहित समस्या यह है कि हमारे पास npm और github पर समान गुंजाइश है।

हम मुख्य रूप से बंद दरवाजों के पीछे विकास कर रहे हैं, हम feature branches > next से हमारी डिज़ाइन टीम के साथ बातचीत/अनुमोदन करने के लिए कैनरी बिल्ड का उपयोग करते हैं, इसलिए इस संदर्भ में कैनरी बिल्ड अभी भी हमारे लिए उपयोगी हैं। npm प्लगइन वर्तमान में इस कार्यक्षमता के लिए प्रदान करता है, इसलिए इसे खोना शर्म की बात होगी।

मुझे लगता है कि जीएचपीआर का उपयोग करने का संदर्भ आम तौर पर यह है कि निजी "संगठन" संदर्भ में प्रकाशित करने के लिए यह प्राथमिक स्थान है और यदि कोई घटक सार्वजनिक किया जाना है, तो npmjs.org माध्यमिक है। (मैंने किसी को जीथब से सार्वजनिक घटकों को स्थापित करते नहीं देखा है)। खुले स्रोत के संदर्भ में, यह आम तौर पर npmjs है, कोई GHPR या कोई अन्य निजी पैकेज रजिस्ट्री नहीं है।

एक तरफ ध्यान दें, चूंकि आप एक विशिष्ट GHPR प्लगइन का उल्लेख करते हैं: हमने एक ऑटो प्लगइन बनाने के लिए अगले सप्ताह के लिए कुछ समय अलग रखा है जो कुछ नियमों के आधार पर पैकेज संस्करणों को हटा देगा (orgs पैकेज के 50Gb तक सीमित हैं, और इसमें docker शामिल है) इमेजिस)

• सीमा में अंतिम कैनरी निकालें
• श्रेणी में nth last next को हटा दें
• ...

v10 पर काम शुरू होने तक मैं आपके साथ एक विशिष्ट ghpr प्रकाशक बनाने के लिए खुशी से प्रतीक्षा करूंगा, यहां प्रस्तुत विचार बहुत रोमांचक लगते हैं और शायद अधिक "भविष्य के प्रमाण" हैं।

हम कुछ समय के लिए एक ही समय में सार्वजनिक और निजी प्रकाशित किए बिना रह सकते थे, लेकिन कम से कम आप जानते हैं कि यह मेरे लिए उपयोग का मामला है।

मैं "माध्यमिक पैकेज रजिस्ट्री" प्लगइन के बारे में अधिक सोच रहा था। तो एनपीएम प्लगइन काम करेगा जैसा कि करता है, जो भी रजिस्ट्री कॉन्फ़िगर किया गया है उसे प्रकाशित करना। फिर यह नया प्लगइन एक दूसरी रजिस्ट्री पर प्रकाशित होगा (चाहे वह npm या ghpr कोई फर्क नहीं पड़ता) जो भी संस्करण HEAD कमिट पर हैं, उन्हें जारी करना।

एक तरफ ध्यान दें, चूंकि आप एक विशिष्ट GHPR प्लगइन का उल्लेख करते हैं: हमने एक ऑटो प्लगइन बनाने के लिए अगले सप्ताह के लिए कुछ समय अलग रखा है जो कुछ नियमों के आधार पर पैकेज संस्करणों को हटा देगा (orgs पैकेज के 50Gb तक सीमित हैं, और इसमें docker शामिल है) इमेजिस)

यह एक अच्छी सुविधा की तरह लगता है। मुझे नहीं पता था कि वे सीमाएं मौजूद हैं!

यह नया प्लगइन दूसरी रजिस्ट्री पर प्रकाशित होगा (चाहे वह npm हो या ghpr कोई फर्क नहीं पड़ता) जो भी संस्करण HEAD कमिट पर हैं, उन्हें जारी करना

अच्छा यह निश्चित रूप से काम करेगा! संपादित करें: हमारे परिदृश्य के लिए भी

नमस्ते! इस थ्रेड के संबंध में ऑटो की वर्तमान स्थिति क्या है? क्या एक ही रिलीज से एक से अधिक चीजें प्रकाशित करना संभव है?

चूंकि प्रत्येक पैकेज मैनेजर प्लगइन पैकेज मैनेजर के लिए कुछ अतिरिक्त फाइल पर निर्भर करता है (सभी git-tag को छोड़कर)

मुझे लगता है कि यह गलत धारणा है। क्या docker प्लगइन किसी फ़ाइल पर निर्भर करता है? यह इसके लिए अनावश्यक हो सकता है, तो शायद यह एक बुरा उदाहरण है। यहां एक और है: मुझे एसबीटी (

यह स्वतंत्र मोनोरेपो प्रबंधन को बहुत सरल तरीके से पूरा करता है

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

प्रत्येक प्लगइन वर्तमान में कमिट, टैग और पुश करता है। यह बहुत शोर पैदा करेगा। शायद उन गिट क्रियाओं को कोर में ले जाना होगा, इसलिए यह केवल एक बार होता है? हालांकि आप प्रत्येक package लिए _want_ अलग कमिट कर सकते हैं।

मुझे लगता है कि प्लगइन के वर्तमान कार्यान्वयन के साथ यह मुख्य मुद्दा है। यह इस दावे के बारे में मेरे भ्रम पर वापस जाता है कि प्रत्येक आदेश "केवल एक ही चीज़ वास्तव में अच्छी तरह से करता है"। मेरी राय में publish हुक वास्तव में दिए गए पैकेज मैनेजर के लिए _only publish_ होना चाहिए, न कि कमिट बनाना या गिट टैग को पुश करना। यदि प्रत्येक प्रकाशन प्लगइन केवल अपने पैकेज प्रबंधक विनिर्देशों के कार्यान्वयन पर ध्यान केंद्रित कर सकता है, तो प्रक्रिया के सामान्य भागों का पुन: उपयोग और/या साझा किया जा सकता है। क्या ऑटो के साथ इसे हासिल करना अभी भी संभव है या क्या यह एनपीएम जैसी परियोजनाओं के प्रति बहुत पक्षपाती है?