مرکزی مواد پر جائیں
اے آئی ٹیوٹوریلز

RepoPilot کے ذریعے تصدیق پر مبنی GitHub Issue اور PR کی اصلاحات کیسے چلائیں

RepoPilot انسٹال کرنے، قابلِ اعتماد ٹیسٹس اور ریپوزٹری پالیسیز ترتیب دینے، پل ریکوئسٹس کا جائزہ لینے، Issues کو دوبارہ پیش کرنے، Codex سے تیار کردہ اصلاحات کی تصدیق کرنے، کاموں کا نظم سنبھالنے، اور اختیاری طور پر اہل اصلاحات کو ڈرافٹ پل ریکوئسٹس کے طور پر شائع کرنے کا طریقہ سیکھیں، جبکہ مینٹینرز کا اختیار برقرار رہے۔

تقریباً 29 منٹ کا مطالعہ
RepoPilot کے ذریعے تصدیق پر مبنی GitHub Issue اور PR کی اصلاحات کیسے چلائیں

RepoPilot کیا کرتا ہے

RepoPilot تصدیق پر مبنی سافٹ ویئر تکرار کے لیے ایک خود میزبان کنٹرولر ہے۔ یہ منتخب GitHub Issues اور اسی ریپوزٹری کی pull requests کو ایک محدود ورک فلو میں تبدیل کرتا ہے، جس میں قواعد کا جائزہ، ٹیسٹ کی تیاری، ناکامی کی دوبارہ تخلیق، کوڈ کی مرمت، آزادانہ تصدیق، اور مرمت کی برانچ اور draft pull request کی اختیاری اشاعت شامل ہے۔

یہ منصوبہ OpenAI Codex SDK استعمال کرتا ہے تاکہ ریپوزٹری کے قواعد سمجھے، ضروریات پر مبنی ٹیسٹ تیار کرے، اور پروڈکشن کوڈ میں تبدیلیاں تجویز کرے۔ ایک علیحدہ Docker runner پن شدہ ریپوزٹری snapshots کے خلاف ٹیسٹ چلاتا ہے۔ کنٹرولر نتیجہ صرف اس وقت شائع کرتا ہے جب ترتیب دیے گئے شواہد اور پالیسی چیکس کامیاب ہوں۔

RepoPilot تبدیلیوں کو خودکار طور پر merge یا deploy نہیں کرتا۔ Maintainers کام منتخب کرتے ہیں، شواہد کا جائزہ لیتے ہیں، اور حتمی merge کا فیصلہ اپنے پاس رکھتے ہیں۔

ورک فلو کی حدود

  1. RepoPilot متعلقہ base اور head commits کو پن کرتا ہے۔
  2. یہ base branch سے قابلِ اعتماد پالیسی لوڈ کرتا ہے، جس میں قابلِ اطلاق AGENTS.md رہنمائی شامل ہے۔
  3. Codex تبدیلی کا جائزہ لیتا ہے اور ٹیسٹ یا مرمت کے امیدوار تجویز کرتا ہے۔
  4. پروڈکشن کوڈ کی مرمت سے پہلے تیار کردہ ٹیسٹ منجمد کر دیے جاتے ہیں۔
  5. ایک علیحدہ runner آزاد snapshots کے خلاف ٹیسٹ چلاتا ہے۔
  6. کنٹرولر مستحکم ٹیسٹ شناختوں، ناکامی کے fingerprints، محفوظ paths، پالیسی نتائج، اور ترتیب دی گئی حدود کو چیک کرتا ہے۔
  7. اہل نتیجہ ایک علیحدہ branch پر رکھا جا سکتا ہے اور انسانی جائزے کے لیے draft pull request کے طور پر جمع کیا جا سکتا ہے۔

Pull requests کے لیے RepoPilot base اور head کے رویے کا موازنہ کرتا ہے۔ Issues کے لیے یہ پہلے اصل baseline کے کامیاب ہونے کا تقاضا کرتا ہے، پھر مرمت تجویز کرنے سے پہلے نئی منجمد کی گئی ٹیسٹ کے ذریعے رپورٹ شدہ خرابی کو دوبارہ پیدا کرنے کی کوشش کرتا ہے۔

اہم خصوصیات اور موجودہ دائرۂ کار

  • پن شدہ inputs: Base اور head SHAs، title اور body digests، تازگی کے چیکس، اور cancellation، پرانے inputs کے خلاف تصدیق کو روکنے میں مدد دیتے ہیں۔
  • قابلِ اعتماد ریپوزٹری قواعد: Static policies لفظی checks اور JavaScript یا TypeScript call rules کو سپورٹ کرتی ہیں۔ Nested base-branch AGENTS.md فائلیں semantic review کی رہنمائی کر سکتی ہیں۔
  • آزادانہ ٹیسٹ اجرا: کنٹرولر model کے جائزے پر بھروسا کرنے کے بجائے اجرا ایک علیحدہ Docker runner کے حوالے کرتا ہے۔
  • متعدد ٹیسٹ ecosystems: Version 1.3.0، Node کا test runner، Vitest، pytest، Go tests، اور compatible JUnit XML evidence کو سپورٹ کرتا ہے۔
  • Monorepo سپورٹ: Configurations میں working directories، متعدد نامزد test commands، اور عارضی dependency services استعمال کی جا سکتی ہیں۔
  • محدود مرمت: کوششوں، retries، model calls، tokens، task executions، اور مجموعی task time کی حدود مقرر کی جا سکتی ہیں۔
  • قابلِ سراغ رپورٹس: Atomic JSON reports اور مختصر Markdown summaries findings، test outcomes، patches، attempts، اور publication state محفوظ رکھتے ہیں۔
  • آپریشنل بحالی: Task commands inspection، cancellation، resumption، اور reruns کو سپورٹ کرتی ہیں۔ recover flow preview اور validated cleanup کے ذریعے اپنے زیرِ ملکیت crash leftovers کو سنبھالتا ہے۔

موجودہ implementation عوامی، text-based ریپوزٹریز کو ہدف بناتی ہے جن میں زیادہ سے زیادہ 10,000 فائلیں یا 16 MiB ہوں۔ یہ fork pull-request execution، browser end-to-end testing، hosted dashboard، webhooks، distributed queue، automatic dependency installation، automatic merging، یا deployment فراہم نہیں کرتی۔

ضروریات

اگر آپ Node.js انسٹال نہیں کرنا چاہتے تو Linux، Windows، یا macOS کے لیے RepoPilot 1.3.0 portable release ڈاؤن لوڈ کر سکتے ہیں۔ Source installation کے لیے درج ذیل تیار کریں:

  • Node.js 22، جو تجویز کردہ version ہے
  • npm اور Git
  • Linux containers چلانے کے لیے configured Docker
  • جب Codex-based review، test planning، یا repair فعال ہو تو OpenAI API key
  • جب GitHub access یا publication درکار ہو تو GitHub token

1.3.0 controller اور Agent image versions ایک جیسے رکھیں۔ Docker images اور project dependencies پہلے سے provision ہونی چاہییں، کیونکہ test containers میں by default network access نہیں ہوتا۔

RepoPilot کو Source سے انسٹال کریں

1. Project انسٹال، validate، اور build کریں

کلون کی گئی RepoPilot ریپوزٹری سے locked dependencies انسٹال کریں، project checks اور tests چلائیں، اور controller build کریں:

npm ci
npm run check
npm test
npm run build

RepoPilot کے اپنے development tests mocked APIs، agents، runners، اور synthetic fixtures استعمال کرتے ہیں۔ یہ model credits استعمال نہیں کرتے، Docker لانچ نہیں کرتے، اور GitHub content نہیں لکھتے۔

2. مقامی configuration بنائیں

فراہم کردہ example configuration نقل کریں:

cp repopilot.example.json config.local.json

PowerShell صارفین cp کے بجائے Copy-Item استعمال کر سکتے ہیں۔ ہدف ریپوزٹری اور قابلِ اعتماد test command مقرر کرنے کے لیے config.local.json میں ترمیم کریں۔ اس local configuration کو زیرِ جائزہ ریپوزٹری snapshots سے باہر رکھیں۔

Example configuration agent review، repair، اور publishing کو غیر فعال رکھتی ہے۔ ان صلاحیتوں کو الگ الگ صرف اس وقت فعال کریں جب local verification کام کر رہی ہو۔

3. Codex Agent image بنائیں

جب آپ Codex-based semantic review، test planning، یا repair چاہتے ہوں تو Agent container build کریں:

docker build -f Dockerfile.agent -t repopilot-agent:local .

Controller environment میں OPENAI_API_KEY مقرر کریں۔ یہ key صرف Agent container کو ملتی ہے۔ Desktop ChatGPT credentials دوبارہ استعمال نہیں کیے جاتے۔ GITHUB_TOKEN یا GH_TOKEN کے ذریعے فراہم کردہ GitHub credential controller میں ہی رہتا ہے۔

اپنی پہلی مقامی Pull Request Check چلائیں

ایک مقامی موازنے سے آغاز کریں جس میں بنیادی برانچ اور فیچر برانچ کا تقابل ہو:

npm run dev -- check --config config.local.json --repo /path/to/project --base main --head feature

/path/to/project، main، اور feature کو اپنی مقامی ریپوزٹری اور ریفرنسز سے تبدیل کریں۔ مقامی check تبدیلیاں شائع نہیں کرتا اور سورس چیک آؤٹ میں ترمیم نہیں کرتا۔

RepoPilot جنریٹ کیے گئے ٹیسٹس کی درجہ بندی کیسے کرتا ہے

جنریٹ کیے گئے منظرناموں کو regression یا new_behavior میں درجہ بند کیا جاتا ہے۔ ڈیفالٹ درجہ بندی regression ہے۔

  • Regression کا ثبوت: ایک ہی چلایا گیا ٹیسٹ کیس بنیادی revision پر کامیاب اور head revision پر ناکام ہو۔
  • New behavior کا ثبوت: کیس base پر ناکام اور head پر کامیاب ہو، اور مجوزہ ٹیسٹ میں pull request کے عنوان یا متن سے عین تقاضے کا اقتباس شامل ہو۔
  • جائزہ ضروری ہے: دونوں revisions ناکام ہوں، کوئی کیس چھوڑ دیا گیا ہو یا غائب ہو، execution ناکام ہو، test discovery تبدیل ہو، یا اصل ٹیسٹ کے نتائج غیر متوقع طور پر بدل جائیں۔

ماڈل کی فراہم کردہ لیبل runner کے ثبوت کو تبدیل نہیں کر سکتی۔ خودکار مرمت کے اہل ہونے سے پہلے regressions کو یکساں ناکام ٹیسٹ شناختوں اور fingerprints کے ساتھ دوبارہ ظاہر ہونا ضروری ہے۔

Pull Requests کا مسلسل جائزہ لیں

RepoPilot غیر draft، اسی ریپوزٹری کی pull requests کو poll کرتا ہے اور اپنی autofix برانچز کو خارج کرتا ہے۔ کنفیگریشن کی توثیق کے دوران polling کا ایک چکر چلائیں:

npm run dev -- watch --config config.local.json --once

نتائج کی تصدیق کے بعد watcher کو مسلسل چلائیں:

npm run dev -- watch --config config.local.json

اشاعت اختیاری ہے اور اس کے لیے publish=true ضروری ہے۔ GitHub token کے پاس repository Contents اور Pull requests کے لیے write permissions ہونی چاہییں۔ اشاعت الگ autofix برانچز اور draft pull requests بناتی ہے؛ یہ کبھی force-push یا خودکار merge نہیں کرتی۔

اشاعت سے پہلے RepoPilot commit SHAs اور pull-request کے متن کی دوبارہ جانچ کرتا ہے۔ موجودہ repair branch یا pull request صرف اسی وقت دوبارہ استعمال کی جا سکتی ہے جب اس کا parent اور tree تصدیق شدہ نتیجے سے مطابقت رکھتے ہوں۔

GitHub Issue کو دوبارہ پیش کریں اور مرمت کریں

Issue کی مرمت maintainer کے ذریعے واضح طور پر منتخب کی جاتی ہے۔ Issue 123 پر کارروائی کرنے کے لیے چلائیں:

npm run dev -- fix --issue 123 --config config.local.json

Issue workflow تین اہم مراحل میں آگے بڑھتا ہے:

  1. Baseline قائم کریں: pinned target revision پر موجودہ ٹیسٹس کا کامیاب ہونا ضروری ہے۔
  2. بگ دوبارہ پیش کریں: RepoPilot Issue کی تفصیل سے منسلک ایک ٹیسٹ جنریٹ اور freeze کرتا ہے۔ نئے ٹیسٹ کو رپورٹ کی گئی ناکامی دوبارہ پیش کرنی چاہیے۔
  3. مرمت کی کوشش اور تصدیق: Codex کوڈ replacements تجویز کرتا ہے، اور آزاد runner frozen generated test، اصل suite، اور repository policy کی جانچ کرتا ہے۔

ناکافی، غیر مستحکم، یا نامکمل ثبوت workflow کو انسانی جائزے کے لیے روک دیتے ہیں۔ RepoPilot خودکار طور پر Issues منتخب نہیں کرتا، product roadmap متعین نہیں کرتا، اور نتیجے میں حاصل ہونے والی مرمت کو merge نہیں کرتا۔

قابلِ اعتماد Repository Policy شامل کریں

ہدف base branch میں .repopilot/policy.json commit کریں۔ مثال کے طور پر، درج ذیل rule غیر فعال JavaScript اور TypeScript ٹیسٹس کو مسترد کرتا ہے:

{
  "rules": [
    {
      "id": "no-disabled-tests",
      "kind": "forbid-call",
      "extensions": [".ts", ".js"],
      "callee": "test.skip",
      "message": "Keep regression tests enabled.",
      "severity": "error"
    }
  ],
  "exceptions": []
}

موزوں static rule kinds میں forbiddenText، forbid-call، اور require-call شامل ہیں۔ Call rules براہِ راست calls، qualified calls، اور string property access کا معائنہ کرتے ہیں۔ یہ aliases حل نہیں کرتے اور نہ ہی whole-program analysis انجام دیتے ہیں۔ Literal rules تبصروں سے بھی مطابقت پیدا کر سکتے ہیں۔

Policy exceptions میں ruleId، عین path، وجہ، UTC expiration timestamp، اور اختیاری عین evidence کی نشاندہی کی جا سکتی ہے۔ Exceptions صرف اسی وقت قابلِ اعتماد سمجھی جاتی ہیں جب وہ base policy سے آئی ہوں، اور ختم شدہ exceptions findings کو suppress نہیں کرتیں۔

ایک دوسرے پر لاگو ہونے والے required اور forbidden rules جائزہ روک دیتے ہیں۔ وہ pull requests جو قابلِ اعتماد rule files میں ترمیم کریں، maintainer کے جائزے کے متقاضی ہیں اور اپنی مرمت کی خود اجازت نہیں دے سکتیں۔

Test Evidence کو احتیاط سے Configure کریں

ڈیفالٹ reporter node ہے اور node --test استعمال کرتا ہے۔ پہلے RepoPilot build کریں تاکہ قابلِ اعتماد reporter دستیاب ہو۔ Vitest کے لیے reporter=vitest configure کریں اور pinned dependencies والی قابلِ اعتماد image میں واضح vitest run command استعمال کریں۔

  • Reporter flags controller سے متعلق ہوتے ہیں، ناقابلِ اعتماد test command سے نہیں۔
  • reporter=command صرف output جمع کرتا ہے اور verification یا publication کی معاونت نہیں کر سکتا۔
  • Runner کو چھوڑنے سے صرف policy-based review ہوتا ہے، اور ٹیسٹس not_run کے طور پر ریکارڈ ہوتے ہیں۔
  • صفر ٹیسٹس، تمام skipped ٹیسٹس، malformed reports، اور غائب test identities کو کبھی کامیاب نہیں سمجھا جاتا۔
  • Configured dependency services ایک عارضی internal Docker network استعمال کرتی ہیں۔

ایسے generated tests کے لیے جن میں base revision پر موجود نہ ہونے والے exports شامل ہوں، executing test cases کے اندر ان exports کی جانچ کریں۔ structured evidence جمع ہونے سے پہلے کسی غائب export کو top-level import کو crash نہیں کرنا چاہیے۔

چلتے اور مکمل شدہ Tasks کا نظم کریں

RepoPilot reports اور snapshots کو .repopilot-data کے تحت محفوظ کرتا ہے۔ ہر task کو JSON evidence اور Markdown summary ملتی ہے۔ دوبارہ چلائی گئی executions سابقہ evidence کو TASK.execution-N.json جیسے ناموں سے archive کرتی ہیں۔

Tasks کا معائنہ اور منسوخی

npm run dev -- tasks list --config config.local.json --status running --limit 20 --offset 0
npm run dev -- tasks show TASK_ID --config config.local.json --format markdown
npm run dev -- tasks cancel TASK_ID --config config.local.json

کنٹرولر کے رائٹر لاک کو برقرار رکھنے کے دوران ٹاسکس کی فہرست دیکھنا، دکھانا اور منسوخ کرنا دستیاب رہتا ہے۔ منسوخی ایک مستقل درخواست بناتی ہے جسے تصدیق اور اشاعت کے دوران چیک کیا جاتا ہے۔ یہ GitHub پر پہلے ہی مکمل ہو جانے والی تحریری کارروائیوں کو واپس نہیں کر سکتی۔

کام دوبارہ شروع کریں یا دوبارہ چلائیں

npm run dev -- tasks resume TASK_ID --config config.local.json
npm run dev -- tasks rerun TASK_ID --config config.local.json

resume ٹاسک کی شناخت، کنفیگریشن اور حدود برقرار رکھتا ہے۔ حالت کے لحاظ سے یہ تصدیق دوبارہ شروع کرتا ہے یا پہلے سے تصدیق شدہ ٹاسک کی اشاعت جاری رکھتا ہے۔ rerun اصل پن کیے گئے کمٹس اور موجودہ کنفیگریشن کا استعمال کرتے ہوئے ایک منسلک ٹاسک بناتا ہے، جبکہ سابقہ رپورٹس اور منسوخی کے نشانات محفوظ رہتے ہیں۔

مستقل، اختتامی یا ختم شدہ ٹاسکس کے لیے rerun ضروری ہے۔ Replay کے لیے ریکارڈ شدہ مقامی repository یا Git cache بھی درکار ہوتا ہے، اور pull-request inputs کو replay کے دوران دوبارہ چیک کیا جاتا ہے۔

اعلیٰ درجے کے عملی مشورے

محتاط حدود استعمال کریں

ٹاسک timeout، maxCalls، maxAttempts، maxTaskExecutions اور token usage کے لیے محدود اقدار مرتب کریں۔ maxTokens کی قدر ہر model call کے بعد رپورٹ ہونے والے استعمال سے حساب کی جاتی ہے، اس لیے ایک کال اس حد سے تجاوز کر سکتی ہے۔ اسے اخراجات کی سخت مالی حد نہ سمجھیں۔

ماحولیاتی ناکامیوں کو الگ سمجھیں

RepoPilot ناکامیوں کی درجہ بندی کرتا ہے اور اہل ماحولیاتی مسائل پر مرحلے کی سطح پر محدود retries لاگو کرتا ہے۔ غیر مستحکم ٹیسٹس، بدلتی ہوئی discovery یا نامکمل evidence خودکار repair کو روک دیتے ہیں، بجائے اس کے کہ انہیں تصدیق شدہ code defects سمجھا جائے۔

ثبوت کی زنجیر محفوظ رکھیں

Repair candidates کو generated test identities برقرار رکھنی ہوں گی اور workflow کے تقاضوں کے مطابق original base، original head اور generated cases منتقل کرنے ہوں گے۔ موجودہ tests، manifests، configurations، policies اور hidden paths محفوظ رہتے ہیں۔ Candidate repair کے بعد static اور semantic policy checks دوبارہ چلائے جاتے ہیں۔

کریش کے بعد احتیاط سے بحال کریں

Version 1.3.0 میں recover workflow شامل ہے، جو مداخلت کا شکار ٹاسکس کی ملکیت والے resources کا پیش نظارہ اور واضح صفائی فراہم کرتا ہے۔ پرانے process کو ہٹانے سے پہلے تصدیق کریں کہ وہ رک چکا ہے۔ پرانے locks اور resources کے لیے دستی معائنہ ضروری ہو سکتا ہے۔

اعتماد کی حد سمجھیں

کنٹرولر، رپورٹس اور runner آپ کی مشین یا worker پر کام کرتے ہیں، لیکن Codex model calls OpenAI services استعمال کرتی ہیں اور منتخب repository text اور task context بھیجتی ہیں۔ RepoPilot کو self-host کرنے سے offline model inference دستیاب نہیں ہوتی۔

ٹیسٹ کا execution engineering evidence فراہم کرتا ہے، malicious code کے خلاف tamper-proof attestation نہیں۔ Symlinks، submodules، binaries اور case-colliding paths کو محفوظ طور پر ناکام کر دیا جاتا ہے۔ غیر معتبر repositories چلانے سے پہلے پروجیکٹ کی security guidance کا جائزہ لیں۔

نتیجہ

RepoPilot Codex-assisted review اور repair کو pinned inputs، frozen tests، independent Docker execution، repository policy، محدود retries اور پائیدار evidence کے ساتھ یکجا کرتا ہے۔ ابتدا non-publishing مقامی check سے کریں، اپنے reporter اور policy configuration کی توثیق کریں، پھر watching، Issue repair اور draft pull-request publication اسی وقت شامل کریں جب evidence آپ کی ٹیم کے معیارات پر پورا اترے۔