Skip to content
Apothem
सुरक्षा

ब्रांच सुरक्षा

main पर Apothem ब्रांच सुरक्षा: लाइव सुरक्षा नियम, उसके आवश्यक स्टेटस चेक, और जोड़े जाने के लिए लंबित चेक।

Apothem की main ब्रांच एक क्लासिक GitHub ब्रांच सुरक्षा नियम द्वारा सुरक्षित है। रिपॉज़िटरी में कोई रूलसेट नहीं है। यह सुरक्षा rules/production-ready-prs.md में घोषित चेंज-सेट अनुशासन को लागू करती है और OpenSSF Scorecard की Branch-Protection और Code-Review जाँचों को इनपुट देती है।

यह पृष्ठ लाइव सेटिंग्स को ठीक उसी रूप में दर्ज करता है जैसा उन्हें 2026-10-07 को GitHub API से अंतिम बार पढ़ा गया था। जो सेटिंग अनुरक्षक लागू करना चाहता है लेकिन अभी तक लागू नहीं की गई है, वह केवल लंबित अनुरक्षक परिवर्तन के अंतर्गत दिखाई देती है।

सुरक्षा सेटिंग्स

सेटिंगAPI फ़ील्डलाइव मानप्रभाव
मर्ज से पहले पुल रिक्वेस्ट आवश्यक करेंrequired_pull_request_reviews (मौजूद)✅परिवर्तन पुल रिक्वेस्ट के माध्यम से main तक पहुँचते हैं।
आवश्यक अनुमोदक समीक्षाएँrequired_approving_review_count0पुल रिक्वेस्ट किसी अनुमोदक समीक्षा के बिना मर्ज होता है। एकल-अनुरक्षक मॉडल देखें।
नई कमिट पर पुराने अनुमोदन रद्द करेंdismiss_stale_reviews✅किसी नए पुश से पहले दिया गया अनुमोदन अब नहीं गिना जाता।
Code Owners से समीक्षा आवश्यक करेंrequire_code_owner_reviews❌दूसरे अनुरक्षक के जुड़ने से पहले इसे सक्षम करने से एकल-अनुरक्षक पुल रिक्वेस्ट गतिरोध में फँस जाते हैं।
सबसे हालिया समीक्षा-योग्य पुश का अनुमोदन आवश्यक करेंrequire_last_push_approval❌GitHub अपेक्षा करता है कि वह अनुमोदन पुश करने वाले के अलावा किसी अन्य व्यक्ति से आए, जो एकल अनुरक्षक प्रदान नहीं कर सकता।
स्टेटस चेक का पास होना आवश्यक करेंrequired_status_checks✅आवश्यक स्टेटस चेक के अंतर्गत सूचीबद्ध 12 संदर्भों का पास होना अनिवार्य है।
मर्ज से पहले ब्रांच का अद्यतन होना आवश्यक करेंrequired_status_checks.strict❌कोई पुल रिक्वेस्ट तब भी मर्ज हो सकता है जब उसके आवश्यक चेक किसी पुराने main के विरुद्ध पास हुए हों। फिर main पर पुश होने पर चलने वाले वर्कफ़्लो मर्ज किए गए परिणाम का परीक्षण करते हैं।
मर्ज से पहले वार्तालाप समाधान आवश्यक करेंrequired_conversation_resolution✅खुले समीक्षा थ्रेड मर्ज को अवरुद्ध करते हैं।
हस्ताक्षरित कमिट आवश्यक करेंrequired_signatures❌रिलीज़ कमिट स्थानीय रूप से हस्ताक्षरित किए जाते हैं। प्रवर्तन तब तक प्रतीक्षा करता है जब तक योगदानकर्ता ऑनबोर्डिंग दस्तावेज़ SSH या GPG हस्ताक्षर सेटअप का वर्णन न कर दें।
रैखिक इतिहास आवश्यक करेंrequired_linear_history✅main के सार्वजनिक इतिहास को एक ही रेखा में रखता है।
ब्रांच लॉक करेंlock_branch❌main मर्ज स्वीकार करता है।
ऊपर दी गई सेटिंग्स को बायपास करने की अनुमति न देंenforce_admins❌ऊपर दी गई सेटिंग्स किसी रिपॉज़िटरी व्यवस्थापक पर बाध्यकारी नहीं हैं। कोई व्यवस्थापक आवश्यक चेक के बिना मर्ज कर सकता है या सीधे main पर पुश कर सकता है।
फ़ोर्स पुश की अनुमति देंallow_force_pushes❌main पर फ़ोर्स पुश सभी के लिए अवरुद्ध हैं, व्यवस्थापकों सहित।
विलोपन की अनुमति देंallow_deletions❌कोई भी main को हटा नहीं सकता, व्यवस्थापकों सहित।

एकल-अनुरक्षक मॉडल

रिपॉज़िटरी का एक ही अनुरक्षक है। GitHub कहता है: "पुल रिक्वेस्ट के लेखक अपने स्वयं के पुल रिक्वेस्ट को अनुमोदित नहीं कर सकते।" इसलिए 0 से अधिक आवश्यक अनुमोदन संख्या अनुरक्षक के हर पुल रिक्वेस्ट को अवरुद्ध कर देगी। लाइव नियम 0 अनुमोदनों के साथ एक पुल रिक्वेस्ट की माँग करता है और enforce_admins को बंद रखता है।

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

जब कोई दूसरा अनुरक्षक जुड़ता है, तब अधिक मज़बूत सेटिंग्स हैं: कम से कम एक आवश्यक अनुमोदन, नवीनतम-पुश अनुमोदन, CODEOWNERS समीक्षा, और enforce_admins चालू। एकल-अनुरक्षक मर्ज समारोह केवल उस सुरक्षा पर लागू होता है जो एक अनुमोदन की माँग करती है और उसे व्यवस्थापकों पर भी लागू करती है।

आवश्यक स्टेटस चेक

इन 12 संदर्भों में से प्रत्येक आवश्यक है, और प्रत्येक का स्रोत GitHub Actions (ऐप ID 15368) है:

quality / ubuntu-latest / py3.10
quality / ubuntu-latest / py3.11
quality / ubuntu-latest / py3.12
quality / ubuntu-latest / py3.13
quality / ubuntu-latest / py3.14
quality / windows-latest / py3.10
quality / windows-latest / py3.11
quality / windows-latest / py3.12
quality / windows-latest / py3.13
quality / windows-latest / py3.14
coverage
Require Signed-off-by
संदर्भवर्कफ़्लो और जॉबयह हर पुल रिक्वेस्ट पर कैसे रिपोर्ट करता है
quality / <os> / py<ver> (10)ci.yml, जॉब qualityci.yml तब चलता है जब कोई पुल रिक्वेस्ट किसी कोड या कॉन्फ़िग पथ को छूता है। केवल-दस्तावेज़ पुल रिक्वेस्ट पर ci-docs-stub.yml वही संदर्भ रिपोर्ट करता है।
coverageci.yml, जॉब coveragequality के समान।
Require Signed-off-bydco.yml, जॉब dcoइसके पुल-रिक्वेस्ट ट्रिगर में कोई paths फ़िल्टर नहीं है, इसलिए यह main के हर पुल रिक्वेस्ट पर चलता है।

quality / ubuntu-latest / py3.15 प्रीरिलीज़ सेल ci.yml में continue-on-error के साथ चलता है और आवश्यक नहीं है। CodeQL, Scorecard और pip-audit सहित कोई भी अन्य वर्कफ़्लो स्टेटस रिपोर्ट कर सकता है, लेकिन उसका परिणाम मर्ज को तब तक गेट नहीं करता जब तक उसका संदर्भ इस सूची में न जोड़ा जाए।

लंबित अनुरक्षक परिवर्तन

अनुरक्षक इन 25 संदर्भों को आवश्यक सूची में जोड़ना चाहता है। प्रत्येक वर्कफ़्लो का हेडर जॉब को एक आवश्यक चेक घोषित करता है, और उसके पुल-रिक्वेस्ट ट्रिगर में कोई paths फ़िल्टर नहीं है, इसलिए वह main के हर पुल रिक्वेस्ट पर चलता है। जब तक कोई संदर्भ जोड़ा नहीं जाता, तब तक उसमें विफलता मर्ज को अवरुद्ध नहीं करती।

clean-install-gate.yml, 7 संदर्भ:

installer-shell-compat / ubuntu-latest
installer-shell-compat / macos-latest
installer-shell-compat / windows-latest
clean-install-gate / ubuntu-latest
clean-install-gate / windows-latest
wheel-smoke / ubuntu-latest
wheel-smoke / windows-latest

harness-matrix.yml, 17 संदर्भ, जॉब के मैट्रिक्स में प्रति अडैप्टर एक matrix (<adapter>):

matrix (antigravity)
matrix (claude-code)
matrix (codebuddy)
matrix (codex)
matrix (cursor)
matrix (gemini-cli)
matrix (github-copilot)
matrix (glm)
matrix (hermes)
matrix (kimi-code)
matrix (kiro)
matrix (open-claw)
matrix (opencode)
matrix (qwen-code)
matrix (trae)
matrix (windsurf)
matrix (zed)

installer-lint.yml, 1 संदर्भ:

installer-lint

एक बार harness-matrix.yml संदर्भ आवश्यक हो जाने पर, कोई नया अडैप्टर पंजीकृत करने से एक matrix (<adapter>) संदर्भ जुड़ता है, और आवश्यक सूची में वह उसी परिवर्तन में जुड़ जाता है। "मर्ज से पहले ब्रांच का अद्यतन होना आवश्यक करें" बंद रहता है। जब कोई लंबित परिवर्तन लागू किया जाए, तो उसे उसी परिवर्तन में ऊपर के लाइव अनुभागों में ले जाएँ।

ऑडिट ताल

इस फ़ाइल की समीक्षा हर सुरक्षा ऑडिट पर और हर रिलीज़-इंजीनियरिंग चेकपॉइंट पर की जाती है। इस फ़ाइल और वास्तविक ब्रांच सुरक्षा कॉन्फ़िगरेशन के बीच विचलन एक उच्च-गंभीरता निष्कर्ष है। लाइव कॉन्फ़िगरेशन इन कमांड से पढ़ें:

gh api repos/ahmed-g-gad/apothem/branches/main/protection
gh api repos/ahmed-g-gad/apothem/rulesets

संदर्भ

OpenSSF Scorecard मुद्रा

Apothem का OpenSSF Scorecard लक्ष्य और स्कोर को बेहतर बनाते रहने के लिए उपयोग की जाने वाली साक्ष्य सतहें।

वेबहुक ऑडिट

Apothem वेबहुक ऑडिट — सीक्रेट रोटेशन, स्कोप-न्यूनीकरण, और Scorecard Webhooks जाँच का प्रमाण।

On this page

सुरक्षा सेटिंग्सएकल-अनुरक्षक मॉडलआवश्यक स्टेटस चेकलंबित अनुरक्षक परिवर्तनऑडिट तालसंदर्भ