स्वचालन और CI/CD: Codex का पृष्ठभूमि में उपयोग

📚 सीरीज नेविगेशन: पिछला लेख [26 Git और GitHub इंटीग्रेशन] आपको स्थानीय रूप से Codex द्वारा ब्रांच व्यवस्थित करना, कमिट लिखना और PR (पुल रिक्वेस्ट) बनाना सिखाता है—जहाँ आप मशीन के सामने होते हैं और Codex आपके साथ काम करता है। यह लेख उस प्रक्रिया को पूर्ण स्वचालन (unattended operation) पर ले जाता है: एक बार कॉन्फ़िगर करने के बाद, PR बनते ही Codex स्वतः समीक्षा करेगा, CI विफल होने पर वह स्वतः समाधान पैच तैयार करेगा, और दैनिक स्तर पर आपको काम का विवरण (Summary) प्रदान करेगा, जिसके लिए आपको लगातार निगरानी रखने की आवश्यकता नहीं होगी। अगला लेख [28 गैर-इंटरैक्टिव मोड codex exec] इस पूरे तंत्र को संचालित करने वाली मुख्य कमांड को विस्तार से समझाएगा।

अक्सर कहा जाता है कि "AI कोडिंग टूल का सबसे बड़ा लाभ यह है कि वह आपके साथ मिलकर काम करता है, कोडिंग के दौरान बातचीत करता है"—लेकिन सच कहें तो, यह बात केवल आधी सच है।

Codex का उपयोग करते हुए मुझे यह समझ आया है कि: इसका वास्तविक लाभ तब मिलता है जब आप मशीन के सामने उपलब्ध नहीं होते। आम結对 (Pair Programming) में आपको प्रत्येक चरण की निगरानी करनी होती है, अर्थात जब तक आप हैं काम चल रहा है, आपके जाते ही काम रुक जाता है। लेकिन सॉफ्टवेयर डेवलपमेंट में कई ऐसे नियमित और उबाऊ कार्य होते हैं—जैसे हर PR पर बुनियादी जाँच करना, रात में CI विफल होने पर एरर देखना, या सप्ताह के अंत में रिपोर्ट तैयार करना—ये कार्य नियमबद्ध होते हैं, लेकिन कोडर इन्हें बार-बार करने से कतराते हैं।

इस प्रकार के नियमित कार्यों के लिए स्वचालन (Automation) सबसे सही साधन है। Codex को CI पाइपलाइन से जोड़कर या टाइमर सेट करके, वह पृष्ठभूमि में एक सजग पहरेदार की तरह काम करता रहता है। इस लेख में हम इसी प्रक्रिया को समझेंगे: इसके दो रास्ते हैं—पहला Codex को GitHub Actions (CI/CD पाइपलाइन) में जोड़ना, और दूसरा Desktop App के Automations द्वारा स्थानीय पृष्ठभूमि कार्य (background tasks) सेट करना। दोनों मिलकर आपके प्रोजेक्ट के लिए एक 24-घंटे चलने वाला स्वचालित सुरक्षा घेरा तैयार करते हैं।

इस लेख को पढ़ने के बाद, आपको मिलेगा:

स्वचालन के दो रास्ते—CI/CD के लिए openai/codex-action और स्थानीय स्तर पर Desktop App के Automations—इनका अंतर।
एक सरल और तुरंत चलने वाली GitHub Action workflow YAML फ़ाइल, और उसकी प्रत्येक लाइन का विवरण।
codex-action के मुख्य इनपुट विकल्प (prompt-file, sandbox, safety-strategy, final-message आदि)।
GitHub Secrets में OpenAI API Key को सुरक्षित रूप से कॉन्फ़िगर करना, और सुरक्षा सावधानियाँ।
Desktop App में Automations कॉन्फ़िगर करने, परिणाम देखने और worktree के अलगाव के नियम।
व्यावहारिक अभ्यास: प्रोजेक्ट के लिए "दैनिक काम की रिपोर्ट" तैयार करने का स्वचालन सेट करना।

⚠️ इस लेख में वर्णित GitHub Actions इनपुट और Automations सेटिंग्स Codex आधिकारिक दस्तावेज़ों (GitHub Action / Automations) पर आधारित हैं।

01 स्वचालन के दो मुख्य रास्ते: अंतर समझें

प्रारंभ में ही दोनों के अंतर को स्पष्ट रूप से समझें:

1. GitHub Action (openai/codex-action): यह GitHub Cloud (रनर मशीनों) पर चलता है, और रिपोजिटरी की घटनाओं (जैसे PR बनना, कोड पुश होना, CI पूरा होना) द्वारा ट्रिगर होता है। यह CI/CD (Continuous Integration / Continuous Delivery) पाइपलाइन का हिस्सा है। इसका उद्देश्य टीम के सामूहिक कोडिंग प्रवाह को व्यवस्थित रखना है: जैसे PR की स्वचालित समीक्षा करना, सुरक्षा द्वार (Quality Gate) जाँचना आदि।
2. Automations (स्थानीय कार्य): यह आपकी स्थानीय मशीन पर ही चलता है जहाँ Codex Desktop App सक्रिय है। यह समय (जैसे प्रतिदिन या cron समय) पर आधारित होता है। इसका उद्देश्य व्यक्तिगत स्तर के नियमित कार्यों को संभालना है: जैसे सुबह प्रोजेक्ट की स्थिति रिपोर्ट तैयार करना, या नियमित रूप से स्थानीय कोड की जाँच करना।

क्यों यह अंतर महत्वपूर्ण है? क्योंकि सही रास्ता न चुनने पर काम नहीं करेगा—जैसे यदि आप चाहते हैं कि हर बार जब कोई नया PR खोले तो स्वतः समीक्षा हो, और इसके लिए आप Desktop App में Automation सेट कर देंगे (तो आपके कंप्यूटर बंद करते ही वह काम करना बंद कर देगा); या आप स्थानीय फ़ाइलों की जाँच के लिए GitHub workflow लिख देंगे (तो वह क्लाउड पर होने के कारण आपकी स्थानीय मशीन की फ़ाइलों तक नहीं पहुँच पाएगा)। सही लक्ष्य के लिए सही माध्यम का चुनाव आवश्यक है।

तुलना: सुरक्षा गार्ड और निजी सचिव से। GitHub Action कंपनी के मुख्य गेट पर खड़े सुरक्षा गार्ड की तरह है—वह आपके घर में नहीं रहता, उसका काम गेट पर नज़र रखना है। जैसे ही गेट पर कोई हलचल (जैसे PR आना) होगी, वह नियमों के अनुसार सुरक्षा जाँच शुरू कर देगा। वहीं, Automations आपके घर के निजी सचिव की तरह है—वह आपकी मशीन पर रहता है, और आपके तय समय (जैसे रोज़ सुबह 9 बजे काम की सूची तैयार करना) पर काम करता है। यदि मशीन बंद है, तो वह भी काम नहीं करेगा।

दोनों की तुलना:

	GitHub Action (`codex-action`)	Automations (Desktop App)
निष्पादन स्थान	GitHub Cloud রানার (क्लाउड)	स्थानीय मशीन (जहाँ Codex App चालू है)
ट्रिगर का माध्यम	रिपोजिटरी घटनाएँ (PR, Push, CI)	समय (शेड्यूल / cron समय)
मानवीय उपस्थिति	आवश्यक नहीं, स्वतः पृष्ठभूमि में	मशीन का ऑन होना और App का सक्रिय होना आवश्यक
मुख्य उपयोग	PR की समीक्षा, सुरक्षा द्वार, CI एरर फिक्स	दैनिक कार्य रिपोर्ट, नियमित सुरक्षा स्कैन, टास्क मॉनिटरिंग
श्रेणी	CI/CD (टीम कोडिंग सुरक्षा)	व्यक्तिगत पृष्ठभूमि कार्य

हम इस लेख में पहले GitHub Actions (धारा 02–05), फिर स्थानीय Automations (धारा 06) और अंत में अभ्यास (धारा 07) को देखेंगे।

💡 संक्षेप में: स्वचालन के दो रास्ते हैं—GitHub Action जो क्लाउड पर रिपोजिटरी घटनाओं पर सक्रिय होता है; तथा Automations जो स्थानीय मशीन पर समय चक्र के अनुसार नियमित कार्य करता है।

02 GitHub Action क्या है

निष्कर्ष: openai/codex-action आधिकारिक रूप से तैयार किया गया GitHub Action है, जो CI रनर मशीन पर Codex CLI को स्वतः स्थापित करता है, OpenAI सर्वर से कनेक्शन जोड़ता है, और निर्दिष्ट निर्देशों के अनुसार codex exec कमांड चलाता है। आपको रनर पर इंस्टॉलेशन की चिंता नहीं करनी होती।

यहाँ मुख्य शब्द codex exec है। यह Codex का गैर-इंटरैक्टिव मोड (non-interactive mode) है—जहाँ कोई चैट इंटरफ़ेस नहीं खुलता, निर्देश देने पर वह चुपचाप पृष्ठभूमि में काम करके परिणाम दे देता है। GitHub Action भी इसी codex exec का उपयोग करता है—यह पूरी प्रक्रिया को केवल एक पैकेज में समेट देता है।

आधिकारिक विवरण:

CI/CD वातावरण में Codex को चलाने, कोड पैच लागू करने या GitHub Actions से समीक्षा टिप्पणियाँ दर्ज करने के लिए Codex GitHub Action (openai/codex-action@v1) का उपयोग करें। यह टूल CLI स्थापित करेगा, API क्रेडेंशियल्स सत्यापित करेगा, और आवश्यक अनुमतियों के साथ codex exec चलाएगा।

तुलना: टूलबॉक्स से। जब आप किसी दूरस्थ स्थान पर काम करने जाते हैं, तो आप या तो सभी कोडिंग टूल्स अलग-अलग ले जा सकते हैं और वहाँ सेट कर सकते हैं; या फिर सीधे एक बना-बनाया टूलबॉक्स (codex-action) ले जा सकते हैं, जिसमें सभी टूल्स पहले से व्यवस्थित हैं और आपको केवल काम शुरू करना है। यह क्रेडेंशियल्स की सुरक्षा को भी मजबूत रखता है।

इसके तीन मुख्य उपयोग:

PR या रिलीज़ पर स्वचालित रूप से Codex समीक्षा परिणाम देखना।
कोड क्वालिटी में सुरक्षा द्वार लगाना, ताकि नियम पास न होने पर बिल्ड आगे न बढ़े।
नियमित कार्यों को स्वचालित करना (जैसे कोड की समीक्षा, रिलीज़ नोट्स तैयार करना)।

ध्यान रखें कि यह प्रतिक्रिया मेंशन आधारित नहीं है। यह Git Actions की घटनाओं (on: pull_request आदि) पर स्वतः सक्रिय होता है, आपके निर्देश देने का इंतज़ार नहीं करता।

💡 संक्षेप में: openai/codex-action आधिकारिक पैकेज है जो CI रनर पर Codex CLI सेट करके codex exec कमांड चलाता है; यह स्वचालित रूप से कोडिंग सुरक्षा और समीक्षा कार्यों को संभालता है।

पूरी प्रक्रिया का चित्र:

CI/CD प्रवाह

यह आरेख दिखाता है कि रिपोजिटरी घटना (जैसे push, PR या scheduler) होने पर workflow सक्रिय होता है; वह क्लाउड रनर पर codex exec कमांड चलाता है; और परिणाम (जैसे समीक्षा कमेंट या कोड पैच) वापस रिपोजिटरी में सहेजता है।

03 GitHub Action workflow YAML का ढांचा

आइए एक वास्तविक कोडिंग समीक्षा workflow की YAML फ़ाइल को समझें—जो PR बनने पर स्वतः कोड की समीक्षा करके कमेंट दर्ज करती है।

तुलना: सुरक्षा गार्ड की ड्यूटी चार्ट से। यहाँ चार्ट दो भागों में विभाजित है: पहला भाग (Job: codex) सुरक्षा इंस्पेक्टर है, जो PR आने पर कोड की जाँच करता है और रिपोर्ट तैयार करता है; दूसरा भाग (Job: post_feedback) रिपोर्टर है, जो उस रिपोर्ट को लेकर PR कमेंट बॉक्स में चिपका देता है। सुरक्षा कारणों से दोनों का काम अलग रखा गया है (ताकि जाँच करने वाले के पास सीधे लिखने की अनुमति न हो)।

YAML फ़ाइल का उदाहरण:

yaml

# फ़ाइल: .github/workflows/codex-review.yml
name: Codex pull request review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  codex:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
          persist-credentials: false

      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          output-file: codex-output.md

  post_feedback:
    runs-on: ubuntu-latest
    needs: codex
    if: needs.codex.outputs.final_message != ''
    permissions:
      issues: write
      pull-requests: write
    steps:
      - name: Post Codex feedback
        uses: actions/github-script@v7
        with:
          github-token: ${{ github.token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: process.env.CODEX_FINAL_MESSAGE,
            });
        env:
          CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}

विवरणों की व्याख्या:

1. on (ट्रिगर घटना): pull_request की opened (PR खुलते ही), synchronize (नया कोड पुश होने पर), या reopened (दुबारा खुलने पर)।

2. checkout (कोड लोड करना): Codex को काम करने के लिए रिपोजिटरी का कोड रनर पर उपलब्ध होना चाहिए। यहाँ persist-credentials: false सुरक्षा के लिए सेट किया गया है ताकि रनर पर अनावश्यक क्रेडेंशियल्स न रहें।

3. Run Codex (मुख्य भाग):

yaml

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt-file: .github/codex/prompts/review.md
    output-file: codex-output.md

यहाँ तीन इनपुट हैं: openai-api-key क्रेडेंशियल्स (Secrets से प्राप्त); prompt-file निर्देश फ़ाइल का पथ जहाँ कोडिंग नियम लिखे हैं; और output-file जहाँ परिणाम सहेजा जाता है।

4. outputs और post_feedback: प्रथम भाग की रिपोर्ट final-message में सुरक्षित होती है; जिसे दूसरा भाग (post_feedback) प्राप्त करके GitHub API द्वारा कमेंट के रूप में दर्ज करता है।

मुख्य आउटपुट पैरामीटर:

यह Action परिणाम को final-message आउटपुट वेरिएबल में सहेजता है। आप इसे अगले जॉब्स में उपयोग कर सकते हैं।

इसे चित्र में देखें:

Action Flow

यह आरेख दिखाता है कि इवेंट शुरू होने से लेकर परिणाम दर्ज होने तक डेटा का प्रवाह कैसे होता है।

आप निर्देशों के लिए prompt-file (फ़ाइल का पथ) या prompt (सीधे टेक्स्ट) में से किसी एक का उपयोग कर सकते हैं (दोनों का एक साथ उपयोग करने पर एरर आएगा)।

💡 संक्षेप में: workflow में घटना ट्रिगर होने पर कोड चेकआउट होता है, codex-action समीक्षा करता है, और रिपोर्ट final-message के माध्यम से कमेंट बॉक्स में पोस्ट की जाती है।

04 Action के मुख्य इनपुट मापदंड

सटीक नियंत्रण के लिए आप निम्नलिखित इनपुट सेट कर सकते हैं:

इनपुट विकल्प	विवरण	टिप्पणी
`prompt` / `prompt-file`	कोडिंग समीक्षा के निर्देश	दोनों में से केवल एक
`sandbox`	सैंडबॉक्स मोड	`workspace-write` / `read-only` / `danger-full-access`
`model` / `effort`	मॉडल और कोडिंग क्षमता	डिफ़ॉल्ट रहने दें
`output-file`	परिणाम फ़ाइल का नाम	समीक्षा रिपोर्ट को सहेजने के लिए
`codex-args`	अतिरिक्त CLI कमांड्स	JSON सूची या स्ट्रिंग
`codex-version`	CLI वर्शन तय करना	डिफ़ॉल्ट रूप से नवीनतम
`codex-home`	Codex की होम निर्देशिका का पथ	कॉन्फ़िगरेशन साझा करने के लिए

महत्वपूर्ण विवरण:

sandbox सुरक्षा सेटिंग्स: हमने लेख 15 में तीन स्तर देखे थे—read-only (केवल पढ़ने की अनुमति), workspace-write (बदलाव करने की अनुमति), और danger-full-access (पूर्ण अनुमति)।

डिफ़ॉल्ट रूप से, codex exec read-only (केवल पढ़ने की अनुमति) पर चलता है।

यदि आपका Action कोड बदलने वाला है (जैसे बग फिक्स करना), तो आपको sandbox: workspace-write लिखना आवश्यक होगा, अन्यथा यह कोड बदल नहीं पाएगा।

codex-args का उपयोग: इसके द्वारा आप CLI के मापदंडों को पास कर सकते हैं। उदाहरण के लिए, JSON आउटपुट प्राप्त करने के लिए --output-schema फ़्लैग पास कर सकते हैं ताकि अगला टूल उसे पार्स कर सके।

output-file का लाभ यह है कि आप समीक्षा परिणाम को Artifact के रूप में सहेज सकते हैं, जिससे बाद में उसे डाउनलोड करके पढ़ा जा सकता है।

Action पृष्ठभूमि में Responses API Proxy का उपयोग करता है ताकि API Key को रनर वातावरण में पूरी तरह सुरक्षित रखा जा सके।

💡 संक्षेप में: Action इनपुट CLI मापदंडों का ही YAML रूप हैं; सैंडबॉक्स डिफ़ॉल्ट रूप से read-only होता है, बदलाव के लिए workspace-write सेट करें; क्रेडेंशियल्स की सुरक्षा के लिए प्रॉक्सी का उपयोग किया जाता है।

05 क्रेडेंशियल्स और सुरक्षा नियम (Secrets Security)

YAML में क्रेडेंशियल्स पास करने के लिए Secrets का उपयोग किया जाता है:

yaml

openai-api-key: ${{ secrets.OPENAI_API_KEY }}

यह सुरक्षा की दृष्टि से अत्यंत महत्वपूर्ण भाग है।

नियम 1: क्रेडेंशियल्स को हमेशा GitHub Secrets में रखें

अपनी OpenAI API Key को कभी भी कोड में सीधे न लिखें, उसे हमेशा GitHub secret (जैसे OPENAI_API_KEY) में सहेजें।

कोड को सार्वजनिक रूप से GitHub पर सहेजते समय यदि API Key सीधे लिखी होगी, तो कोई भी उसका दुरुपयोग कर सकता है और आपका API बजट समाप्त हो सकता है।

तुलना: चाबी को तिजोरी में रखने से। Secrets रिपोजिटरी की सुरक्षित तिजोरी है—जहाँ क्रेडेंशियल्स एन्क्रिप्टेड रहते हैं और रन टाइम पर ही लोड होते हैं।

सहेजने की प्रक्रिया: रिपोजिटरी के Settings → Secrets and variables → Actions में जाएं, New repository secret पर क्लिक करें, नाम OPENAI_API_KEY रखें, और क्रेडेंशियल वैल्यू डालकर सहेजें।

नियम 2: क्रेडेंशियल्स को Job स्तर का पर्यावरण वेरिएबल न बनाएं

यह एक आम कोडिंग चूक है:

क्रेडेंशियल्स को Job स्तर के env: ब्लॉक में घोषित न करें। ऐसा करने पर रनर पर चलने वाली कोई भी थर्ड-पार्टी स्क्रिप्ट या पैकेज क्रेडेंशियल्स को रीड कर सकता है।

क्रेडेंशियल्स को हमेशा विशिष्ट स्टेप के with: ब्लॉक में पास करें, ताकि उसकी विजिबिलिटी केवल उसी स्टेप तक सीमित रहे (जैसा ऊपर उदाहरण में दिखाया गया है)।

नियम 3: रनर पर Codex अनुमतियों को सीमित रखें

सुरक्षा के अन्य विकल्प:

इनपुट विकल्प	विवरण	टिप्पणी
`safety-strategy`	Codex रन होने से पहले root विशेषाधिकार हटाना	डिफ़ॉल्ट `drop-sudo`; Windows पर `unsafe` आवश्यक
`unprivileged-user`	कम विशेषाधिकार प्राप्त विशिष्ट यूज़र (`codex-user`) सेट करना	फ़ाइलें पढ़ने की अनुमतियाँ होनी चाहिए
`read-only`	फ़ाइल संपादन और नेटवर्क ब्लॉक करना	सुरक्षा की अतिरिक्त परत
`sandbox`	आंतरिक सैंडबॉक्स प्रतिबंध	आवश्यक स्तर चुनें
`allow-users` / `allow-bots`	Action ट्रिगर करने वाले उपयोगकर्ताओं को सीमित करना	अनाधिकृत PR समीक्षाओं को रोकने के लिए

safety-strategy का डिफ़ॉल्ट मान drop-sudo है, जो सुरक्षा के लिए आवश्यक है; इसे बंद न करें।
allow-users द्वारा आप तय कर सकते हैं कि केवल आपकी टीम के सदस्य ही इस Action को ट्रिगर कर सकें।

सुरक्षा चेकलिस्ट:

❌ असुरक्षित कोडिंग	✅ सुरक्षित कोडिंग
API Key को सीधे YAML फ़ाइल में लिखना	Secrets में सहेजकर रेफरेंस देना
क्रेडेंशियल्स को Job स्तर पर `env` में डालना	केवल आवश्यक स्टेप के `with` में पास करना
सुरक्षा रणनीति (`safety-strategy`) बंद करना	`drop-sudo` का उपयोग जारी रखना
किसी भी PR पर Action को स्वतः चलने देना	ट्रिगर विशेषाधिकार सीमित रखना
बाहरी कमेंट्स या PR डिस्क्रिप्शन को बिना जाँचे Codex को देना	HTML टिप्पणियों और इंजेक्शन से सावधान रहना

बाहरी इनपुट जैसे PR डिस्क्रिप्शन या कमेंट्स में सुरक्षा निर्देश (Prompt Injection) हो सकते हैं, इसलिए उन्हें Codex को भेजने से पहले जाँच लें। सुरक्षा के लिए Codex स्टेप को हमेशा Job के अंत में रन करें ताकि वह सुरक्षित रहे।

💡 संक्षेप में: सुरक्षा नियम—API Key को Secrets में रखें, उसे जॉब स्तर के env में घोषित न करें, safety-strategy को drop-sudo पर रखें, और इनपुट को जाँचे बिना न भेजें।

06 स्थानीय Automations: समय आधारित पृष्ठभूमि कार्य

अब स्वचालन के दूसरे मार्ग को समझते हैं—Automations (Desktop App के भीतर चलने वाले पृष्ठभूमि कार्य)।

निष्कर्ष: Automations द्वारा Codex समय चक्र के अनुसार पृष्ठभूमि में कार्य करता है, और परिणाम होने पर उन्हें Triage (इनबॉक्स) में भेजता है।

यह चक्र नियमित रूप से चलता है, और रिपोर्ट योग्य परिणाम न होने पर कार्य को स्वतः सहेजकर बंद कर देता है (Archive)।

तुलना: सुरक्षा गार्ड की नियमित गश्त से। वह हर घंटे चक्कर लगाता है, यदि सब ठीक है तो कोई अलार्म नहीं बजता; और यदि कोई खिड़की खुली मिलती है, तो वह रिपोर्ट दर्ज करता है।

इसके मुख्य उपयोग:

"दैनिक काम की रिपोर्ट तैयार करना": पिछले 24 घंटों के कमिट्स को पढ़कर टीम के लिए समरी तैयार करना।
नियमित कोडिंग जाँच: प्रोजेक्ट में सुरक्षा बग्स जाँचना।
टास्क मॉनिटरिंग: चल रहे लंबे प्रोजेक्ट्स की प्रगति जाँचना।

दो प्रकार के Automations:

श्रेणी	विवरण	उपयोग
स्वतंत्र कार्य (Standalone)	हर बार एक बिल्कुल नया सत्र शुरू होता है	दैनिक कोडिंग रिपोर्ट तैयार करना
थ्रेड आधारित (Thread Automation)	पहले से चल रहे सत्र में ही काम आगे बढ़ता है	चल रहे कोडिंग टास्क की समय-समय पर जाँच करना

स्वतंत्र कार्य प्रत्येक बार नई रिपोर्ट के लिए उपयुक्त हैं। थ्रेड आधारित कार्यों के निर्देशों को स्पष्ट रखें ताकि वह समझ सके कि प्रत्येक बार सक्रिय होने पर उसे क्या करना है।

निष्पादन निर्देशिका: Local बनाम Worktree

Git प्रोजेक्ट्स के लिए आप तय कर सकते हैं कि Automation कहाँ रन हो:

Worktree मोड: यह एक अलग फ़ोल्डर में कोड लोड करके काम करता है, जिससे आपका स्थानीय चालू काम प्रभावित नहीं होता (सुरक्षित तरीका)।
Local मोड: यह आपके वर्तमान कोडिंग फ़ोल्डर में ही काम करता है, जिससे आपके द्वारा संपादित की जा रही फ़ाइलों में बदलाव होने का जोखिम रहता है।

Git प्रोजेक्ट्स के लिए हमेशा Worktree मोड का उपयोग करें ताकि कोडिंग में कोई त्रुटि न आए।

अनुमतियाँ और नियम:

Automations आपके डिफ़ॉल्ट सैंडबॉक्स नियमों का पालन करते हैं। यदि नियम read-only हैं, तो कोडिंग बदलाव विफल हो जाएंगे (आवश्यकता होने पर workspace-write सेट करें)।
ये approval_policy = "never" पर चलते हैं, अर्थात कोडिंग के समय अनुमोदन पॉप-अप नहीं दिखाया जाता क्योंकि आप मशीन पर उपलब्ध नहीं होते। इसलिए सैंडबॉक्स सुरक्षा मजबूत रखें।

अंतिम निर्देश: शेड्यूल करने से पहले निर्देश को एक बार सामान्य चैट में चलाकर देख लें ताकि परिणाम की सत्यता जाँची जा सके।

💡 संक्षेप में: Automations Desktop App का फीचर है; यह चक्र के अनुसार काम करके परिणाम इनबॉक्स में भेजता है; सुरक्षा के लिए इसे हमेशा Worktree मोड में चलाएं।

07 अभ्यास: दैनिक कोडिंग रिपोर्ट का स्वचालन सेट करना

आइए Desktop App में एक स्वचालित "दैनिक कोडिंग रिपोर्ट" सेटअप करने का अभ्यास करें।

आवश्यकता: Desktop App सक्रिय होना चाहिए और प्रोजेक्ट Git रिपोजिटरी होना चाहिए।

चरण 1: निर्देश (Prompt) का परीक्षण करें

सामान्य कोडिंग चैट में यह निर्देश देकर देखें कि परिणाम सही आ रहा है या नहीं:

text

इस रिपोजिटरी के पिछले 24 घंटों के कमिट्स की जाँच करें, और हिंदी में एक संक्षिप्त रिपोर्ट तैयार करें:
- बदलावों को श्रेणियों में विभाजित करें।
- प्रत्येक श्रेणी का विवरण 1-2 वाक्यों में दें।
- यदि कोई कमिट नहीं है, तो कहें: "पिछले 24 घंटों में कोई नया कमिट नहीं मिला है।"

अपेक्षित परिणाम: Codex कमिट इतिहास पढ़कर रिपोर्ट प्रस्तुत करेगा।

चरण 2: इसे स्वचालित कार्य के रूप में सेट करें

परीक्षण सही होने पर चैट में कहें:

text

इस कार्य को प्रतिदिन सुबह 9 बजे चलने वाले एक स्वतंत्र (Standalone) Automation के रूप में सेट करें।
इसे worktree मोड में चलाएं ताकि मेरा स्थानीय काम प्रभावित न हो। यदि कोई कमिट न हो, तो इसे स्वतः आर्काइव कर दें।

अपेक्षित परिणाम: Codex आवश्यक सेटिंग्स और समय चक्र (सुबह 9 बजे) तय कर देगा। आप Desktop App के Automations पैनल में भी इसे मैन्युअल रूप से सेट कर सकते हैं।

समय चक्र के लिए आप cron सिंटैक्स का भी उपयोग कर सकते हैं।

चरण 3: पैनल में जाँच करें

App के Automations पैनल में जाएं।

अपेक्षित परिणाम: सूची में आपको नया शेड्यूल्ड Automation दिखाई देगा।

चरण 4: रन करके जाँच करें

समय का इंतज़ार किए बिना, पैनल में Run बटन पर क्लिक करें।

अपेक्षित परिणाम:

पृष्ठभूमि में काम शुरू होगा।
काम होने पर रिपोर्ट Triage (इनबॉक्स) में दिखाई देगी; यदि कोई कमिट नहीं था तो यह आर्काइव अनुभाग में सहेजी जाएगी।

चरण 5: हटाना

अभ्यास समाप्त होने पर Automation को पैनल से हटा (delete) दें।

💡 संक्षेप में: अभ्यास के चरण हैं—निर्देश का परीक्षण → स्वचालित कार्य के रूप में शेड्यूलिंग (Worktree में) → पैनल में पुष्टि → मैन्युअल रूप से रन करना → रिपोर्ट देखना।

08 सारांश

इस लेख में हमने Codex के स्वचालन (Automation) के दोनों रास्तों को समझा है।

मुख्य बिंदुओं का सारांश:

विषय	GitHub Action	Automations (Desktop App)
वातावरण	GitHub Actions (क्लाउड)	स्थानीय मशीन
ट्रिगर	Git घटनाएँ (PR, Push)	समय चक्र (cron/शेड्यूल)
क्रेडेंशियल्स	GitHub Secrets	स्थानीय क्रेडेंशियल्स
सैंडबॉक्स	डिफ़ॉल्ट `read-only` (बदलाव के लिए `workspace-write` आवश्यक)	डिफ़ॉल्ट सेटिंग्स के अनुसार
अलगाव	स्वतंत्र रनर	Local बनाम Worktree
अनुमोदन नीति	CLI मापदंड आधारित	`approval_policy = "never"`

अब आप यह कर सकते हैं: GitHub Actions और स्थानीय स्वचालन में अंतर बताना, YAML फ़ाइल बनाना, Secrets में क्रेडेंशियल्स सुरक्षित रखना, सुरक्षा नियमों का पालन करना, Desktop App में शेड्यूल्ड कार्य बनाना, और समस्याओं को हल करना।

अगला लेख [28 गैर-इंटरैक्टिव मोड codex exec]—इस लेख में हमने देखा कि दोनों रास्ते आंतरिक रूप से codex exec कमांड का उपयोग करते हैं। अगले लेख में हम इस गैर-इंटरैक्टिव कोडिंग इंजन को गहराई से समझेंगे ताकि आप स्वयं भी कस्टम स्क्रिप्ट्स लिख सकें।

स्वचालन और CI/CD: Codex का पृष्ठभूमि में उपयोग ​

01 स्वचालन के दो मुख्य रास्ते: अंतर समझें ​

02 GitHub Action क्या है ​

03 GitHub Action workflow YAML का ढांचा ​

04 Action के मुख्य इनपुट मापदंड ​

05 क्रेडेंशियल्स और सुरक्षा नियम (Secrets Security) ​

नियम 1: क्रेडेंशियल्स को हमेशा GitHub Secrets में रखें ​

नियम 2: क्रेडेंशियल्स को Job स्तर का पर्यावरण वेरिएबल न बनाएं ​

नियम 3: रनर पर Codex अनुमतियों को सीमित रखें ​

06 स्थानीय Automations: समय आधारित पृष्ठभूमि कार्य ​

दो प्रकार के Automations: ​

निष्पादन निर्देशिका: Local बनाम Worktree ​

अनुमतियाँ और नियम: ​

07 अभ्यास: दैनिक कोडिंग रिपोर्ट का स्वचालन सेट करना ​

08 सारांश ​

अनुशंसित पठन ​

स्वचालन और CI/CD: Codex का पृष्ठभूमि में उपयोग

01 स्वचालन के दो मुख्य रास्ते: अंतर समझें

02 GitHub Action क्या है

03 GitHub Action workflow YAML का ढांचा

04 Action के मुख्य इनपुट मापदंड

05 क्रेडेंशियल्स और सुरक्षा नियम (Secrets Security)

नियम 1: क्रेडेंशियल्स को हमेशा GitHub Secrets में रखें

नियम 2: क्रेडेंशियल्स को Job स्तर का पर्यावरण वेरिएबल न बनाएं

नियम 3: रनर पर Codex अनुमतियों को सीमित रखें

06 स्थानीय Automations: समय आधारित पृष्ठभूमि कार्य

दो प्रकार के Automations:

निष्पादन निर्देशिका: Local बनाम Worktree

अनुमतियाँ और नियम:

07 अभ्यास: दैनिक कोडिंग रिपोर्ट का स्वचालन सेट करना

08 सारांश

अनुशंसित पठन