*** NO_CI *** अभी भी निरंतर अंतर्निहित निर्माण क्यों कर रहा है?

Question

मैंने हाल ही में टीएफएस की "छिपी हुई विशेषता" की खोज की है जो आपको सीआई बिल्ड को बंद करने से रोकने में मदद करता है यदि आपकी टिप्पणी में ***NO_CI*** है।

मेरे पास घर पर चल रहे टीएफएस हैं और यह एक चाल की तरह छोटे चाल काम करता है।

काम पर हम टीएफएस 2010 का भी उपयोग कर रहे हैं। मुझे लगता है कि यह अभी भी सीआई को हमारे सेटअप में लात मारने से रोकता नहीं है।

मेरा सवाल यह है कि सीआई बिल्ड को अवरुद्ध करने के लिए या नहीं, यह निर्धारित करने के लिए ***NO_CI*** यह देखने के लिए वास्तव में कौन सी प्रक्रिया जांचती है? मेरा प्रारंभिक विचार बिल्ड टेम्पलेट को देखना था। मैंने कुछ भी स्पष्ट नहीं देखा। क्या कोई इस में भाग गया है? क्या मुझे आपसे सही दिशा निर्देशन मिलेगा?

Answer 1

यह समस्या मेरे अंत में एक गलती साबित हुई। मेरे निर्माण सफल होने के बाद मेरे पास कुछ स्वचालित चेक-इन सबमिट किए गए हैं। पहले व्यक्ति में ***NO_CI*** शामिल था और दूसरा नहीं था। मुझे एहसास नहीं हुआ कि दूसरा चेक-इन एक पथ में बनाया जा रहा था कि दूसरे निर्माण ने इसके कार्यक्षेत्र में मैप किया था। इस प्रकार, पहला चेक-इन सीआई निर्माण को बंद करने का कारण नहीं बना रहा था, यह दूसरा चेक-इन था।

Answer 2

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

यदि आपकी चेकइन टिप्पणियों में स्ट्रिंग ***NO_CI*** है, लेकिन परिवर्तन अभी भी सीआई बिल्ड को ट्रिगर करते हैं, एटी (ओं) पर ईवेंट लॉग देखें और देखें कि संदेश के साथ कोई चेतावनी है या नहीं "TF215041: परिवर्तन एन को संसाधित करने में विफल "।

यदि आपकी टीम गेटेड चेकइन बिल्ड परिभाषा का उपयोग करती है, तो सुनिश्चित करें कि उन्होंने निर्माण टेम्पलेट से ***NO_CI*** टिप्पणी को अक्षम करने का चयन नहीं किया है ताकि गेटेड चेकइन परिवर्तन को सीआई को ट्रिगर करने की अनुमति मिल सके।