Skip to content
Apothem
रनबुक

एकल अनुरक्षक PR-मर्ज समारोह

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

परियोजना के ब्रांच-प्रोटेक्शन अपरिवर्तनीय के अंतर्गत PR को स्वयं मर्ज करने का प्रामाणिक संदर्भ। जब अनुरक्षक ही लिखने की पहुँच वाला एकमात्र योगदानकर्ता होता है, तब GitHub के ब्रांच-प्रोटेक्शन नियम enforce_admins=true + required_approving_review_count=1 एक स्व-मर्ज गतिरोध उत्पन्न करते हैं, जिसका समाधान यह पृष्ठ दस्तावेज़ित करता है।


1. गतिरोध

रिपॉज़िटरी की main ब्रांच यह प्रोटेक्शन सेट धारण करती है:

  • required_pull_request_reviews.required_approving_review_count: 1
  • enforce_admins: true

ये नियम कई-अनुरक्षक परिदृश्यों के लिए सही हैं (प्रत्येक परिवर्तन किसी सहकर्मी-समीक्षित PR के माध्यम से main तक पहुँचता है; व्यवस्थापक भी छूट प्राप्त नहीं हैं)। पर ये एकल अनुरक्षकों के लिए गतिरोध उत्पन्न करते हैं: GitHub की नीति आपके द्वारा स्वयं बनाए गए PR पर स्व-अनुमोदन की अनुमति नहीं देती, और enforce_admins=true समीक्षा-अनुमोदन आवश्यकता के gh pr merge --admin ओवरराइड को अवरुद्ध कर देता है।

समाधान के तीन मार्ग हैं:

मार्गकब उपयोग करें
अस्थायी-टॉगल समारोह (इस रिपॉज़िटरी के लिए प्रामाणिक)एकल अनुरक्षक स्व-मर्ज के लिए डिफ़ॉल्ट; मर्ज विंडो के बाहर प्रोटेक्शन अपरिवर्तनीय को बनाए रखता है
लिखने की पहुँच वाली CI-बॉट पहचान प्रावधानित करेंकेवल तभी अपनाएँ जब कई-अनुरक्षक ऑनबोर्डिंग निकट हो; बॉट-अनुमोदन प्रोटेक्शन के मानवीय-समीक्षा अभिप्राय को कमज़ोर करता है
required_approving_review_count: 0 को स्थायी रूप से सेट करेंकेवल तभी अपनाएँ जब रिपॉज़िटरी अनिश्चित काल तक एकल-अनुरक्षक बनी रहेगी; यह प्रोटेक्शन के समीक्षा अभिप्राय को उलट देता है

यह रिपॉज़िटरी अस्थायी-टॉगल समारोह को प्रामाणिक मार्ग के रूप में अनुसमर्थित करती है। अन्य दो दस्तावेज़ित आपातकालीन निकास हैं, डिफ़ॉल्ट नहीं।

2. अस्थायी-टॉगल समारोह

समारोह का अपरिवर्तनीय: समारोह के आरंभ की प्रोटेक्शन अवस्था अंत की प्रोटेक्शन अवस्था के बराबर होती है। छूट केवल मर्ज विंडो के भीतर ही रहती है।

मैनुअल रूप:

# 1. Open the PR, push branch, wait for CI green.
gh pr create --base main --head <feature-branch> --title "..." --body "..."
gh pr checks <pr-number>            # poll until all green

# 2. Relax approver-count to 0.
gh api repos/<owner>/<repo>/branches/main/protection/required_pull_request_reviews \
    -X PATCH -F required_approving_review_count=0

# 3. Squash-merge with admin override (admin override now succeeds because the
#    review-approval requirement is the only block enforce_admins refuses).
gh pr merge <pr-number> --squash --delete-branch --admin

# 4. Restore approver-count to 1.
gh api repos/<owner>/<repo>/branches/main/protection/required_pull_request_reviews \
    -X PATCH -F required_approving_review_count=1

रैप किया हुआ रूप: उस परमाणविक Python रैपर के लिए scripts/dev/admin_merge.py देखें, जो चरण 2 → 3 → 4 को एकल गैर-अंतःक्रियात्मक अनुक्रम में निष्पादित करता है और चरण 3 के विफल होने पर try / finally के साथ रोलबैक सुरक्षा प्रदान करता है।

python scripts/dev/admin_merge.py <pr-number>

3. अपरिवर्तनीय

  • टॉगल विंडो न्यूनतम की गई। चरण 2 → 3 → 4 एकल गैर-अंतःक्रियात्मक अनुक्रम में निष्पादित होते हैं। प्रोटेक्शन केवल मर्ज API कॉल की अवधि के लिए ही अपनी शिथिल अवस्था में रहता है — प्रत्येक देखे गए रन में एक सेकंड से कम।
  • पुनर्स्थापन बिना शर्त है। चरण 4 तब भी चलता है जब चरण 3 विफल हो जाए (रैपर का try / finally खंड किसी भी निकास पथ पर पुनर्स्थापन सुनिश्चित करता है)। एक विफल मर्ज प्रयास प्रोटेक्शन को शिथिल अवस्था में नहीं छोड़ता।
  • CI गेटिंग पूरे समय बनी रहती है। required_status_checks टॉगल से अप्रभावित रहता है; मर्ज के लिए अब भी कॉन्फ़िगर किए गए स्टेटस-चेक संदर्भों का हरा होना आवश्यक है।
  • ऑडिट निशान दृश्यमान। gh pr merge --admin एनोटेशन PR के मर्ज मेटाडेटा में दिखाई देता है; प्रोटेक्शन-API टॉगल रिपॉज़िटरी के ऑडिट लॉग में अनुरक्षक की पहचान के अंतर्गत दिखाई देते हैं।

4. समारोह का उपयोग कब न करें

यह समारोह अनुरक्षक के अपने PR के स्व-मर्ज के लिए है। जब कोई सहकर्मी समीक्षक उपलब्ध हो (लिखने की पहुँच वाला योगदानकर्ता), तब मानक gh pr review --approve + gh pr merge --squash --delete-branch मार्ग सही है और समारोह अनावश्यक है।

यदि रिपॉज़िटरी एक दूसरे अनुरक्षक को ऑनबोर्ड करती है, तो समारोह को सेवानिवृत्त कर दें: मानक PR-समीक्षा प्रवाह बिना किसी टॉगल के प्रोटेक्शन के मानवीय-समीक्षा अभिप्राय को पुनर्स्थापित कर देता है।

5. किसी पिछले रन का ऑडिट

प्रत्येक समारोह आह्वान तीन टिकाऊ सतहों पर उतरता है, जिन्हें कोई संचालक बाद में निरीक्षित कर सकता है:

  • PR का मर्ज मेटाडेटा। gh pr view <pr-number> --json mergedBy,mergedAt,mergeCommit मर्ज कर्ता, मर्ज टाइमस्टैम्प, और squash कमिट का SHA लौटाता है। mergedBy कर्ता उस अनुरक्षक पहचान से मेल खाता है जिसने चरण 3 चलाया।
  • रिपॉज़िटरी का ऑडिट लॉग। gh api /repos/<owner>/<repo>/actions/runs --jq '.workflow_runs[] | select(.event=="push")' मर्ज-पश्चात CI रन को मर्ज कमिट से सहसंबद्ध करता है; रिपॉज़िटरी का प्रोटेक्शन-नियम ऑडिट लॉग (Settings → Branches UI के माध्यम से gh api /repos/<owner>/<repo>/branches/main/protection का इतिहास) मर्ज विंडो को घेरते चरण 2 और चरण 4 के टॉगल दिखाता है।
  • अनुरक्षक का git इतिहास। git log main --merges --first-parent main पर प्रत्येक squash-मर्ज कमिट को कमिट विषय में संबंधित PR संख्या (gh pr merge --squash डिफ़ॉल्ट के अनुसार (#<pr-number>) प्रत्यय) के साथ सूचीबद्ध करता है, जिससे संचालक किसी भी पिछले लैंडिंग को उसके PR और समारोह आह्वान तक वापस पता लगा सकता है।

जब scripts/dev/admin_merge.py प्रवेश-बिंदु होता है, तब इसका गैर-अंतःक्रियात्मक लॉग (stdout) तीन प्रोटेक्शन-API कॉल और मर्ज-API कॉल को क्रम में नामित करता है; रैपर को tee में पाइप करने से GitHub-पक्ष की लॉग प्रतिधारण पर निर्भर हुए बिना प्रति-रन ऑडिट अंश कैप्चर हो जाता है।

On this page