मेरे रीडिप्लॉय ने वह बिल्ड रद्द कर दिया जो मेरे बदलाव से शुरू हुआ था
आपने कोई फ़ील्ड बदलने के लिए lizard service set चलाया, फिर lizard redeploy। डिप्लॉय में उम्मीद से ज़्यादा समय लगा, और हिस्ट्री में एक रद्द किया गया बिल्ड दिख सकता है।
इसका क्या मतलब है
service set कॉल ने अपने आप रीबिल्ड पहले ही शुरू कर दिया था। उसके बाद चलाए गए redeploy ने वह बिल्ड रद्द कर दिया, जिसका लॉग --- Build cancelled: a newer deploy was triggered --- पर ख़त्म होता है, और वही बिल्ड शुरू से दोबारा चला दिया।
ऐसा क्यों हो सकता है
किसी सर्विस पर बिल्ड को प्रभावित करने वाला फ़ील्ड — repoUrl, branch, sourceType, buildCommand, dockerfilePath या rootDirectory — बदलते ही चल रही सर्विस अपने आप रीबिल्ड होती है। क्रैश हुई या कभी डिप्लॉय न हुई सर्विस अपने आप रीबिल्ड नहीं होती। सिर्फ़ रनटाइम वाला फ़ील्ड — startCommand, preDeployCommand, containerPort, watchPatterns — बदलने पर अपने आप रीबिल्ड नहीं होता; वह बदलाव सिर्फ़ अगले डिप्लॉय पर लागू होता है।
हर service set के बाद आदतन redeploy चला देना आसान है, लेकिन ऐसा करना सिर्फ़ रनटाइम वाले फ़ील्ड के लिए सही है।
संभावित समाधान
देखें कि आपने किस तरह का फ़ील्ड बदला
रीबिल्ड ट्रिगर करने वाले फ़ील्ड की टेबल देखें। अगर वह बिल्ड फ़ील्ड है और सर्विस चल रही थी, तो रीबिल्ड शुरू हो चुका है — और कुछ न करें। अगर सर्विस क्रैश थी या कभी डिप्लॉय नहीं हुई थी, तो lizard redeploy एक बार चलाएँ।
lizard events # is a build already running?रीडिप्लॉय सिर्फ़ रनटाइम वाले बदलावों के बाद करें
lizard service set api --set startCommand="node server.js"
lizard redeploy --service api # needed here — startCommand doesn't auto-rebuildयह भी देखें
- बिल्ड पाइपलाइन → रीबिल्ड किससे ट्रिगर होता है
lizard service— कमांड का पूरा रेफ़रेंस।
अपडेट: