पाइपलाइन फ़ेलियर की डिबगिंग

यह क्यों ज़रूरी है

लाल pipeline अपने पीछे हर merge और हर release रोक देती है, और ग़लत classification धीमी debugging से भी महँगी है। Product defect को "flaky" कहना उसे users तक पहुँचने देता है; environment की समस्या को product bug कहना developers को ऐसा defect खोजने भेजता है जो code में है ही नहीं। हरा होने तक re-run करना दोनों काम करता है: सबूत छिपाता है और टीम को सिखाता है कि लाल का कोई मतलब नहीं।

Tester का भरोसा यहीं बनता है। जो report failing test, पहली error, artifacts, reproduction command और पहला bad commit बताती है, वह जल्दी ठीक होती है; "pipeline लाल है, कोई देख सकता है?" वाली नहीं।

Log और artifacts से शुरू करें

Automation reporting और debugging वाले lesson की तरह पहली error और उसके सबूत से शुरू करें; pipeline में इसका मतलब है पहले पहला failed job और उसके अंदर पहला failed step ढूँढना। Scroll करने की बजाय log में test का नाम या error marker (GitHub Actions के raw log में ##[error]) search करें, और याद रखें कि runner के timestamps आम तौर पर UTC में होते हैं।

फिर retention period ख़त्म होने से पहले job के artifacts डाउनलोड करें, जैसे JUnit XML report, Playwright trace और application logs, और उन्हें उसी lesson की तरह पढ़ें। इन्हें job के आख़िरी green run से मिलाएँ: नई runner image, बदली हुई dependency या कम tests का चलना, code पढ़ने से पहले ही मिलने वाले सुराग हैं।

# GitHub CLI: logs of the failed steps only, then the artifacts of one job
gh run view 9876543 --log-failed
gh run download 9876543 -n e2e-results-3

# open the trace recorded for the failing test
npx playwright show-trace test-results/invoice-order-date/trace.zip

आज़माएँ: XML फ़ॉर्मेटर आज़माएँ: टेक्स्ट डिफ़

Failure को locally reproduce करें

जो failure आप अपनी machine पर reproduce कर सकते हैं, उसे debugger, extra logging और जितने चाहें उतने runs से जाँचा जा सकता है। Reproduction parity का मामला है: हर उस चीज़ में CI job से मेल बिठाएँ जो result बदल सकती है, फिर एक बार में एक ही चीज़ बदलें। अगर test locally फिर भी pass हो, तो बचा हुआ फ़र्क़ ही आपका सबसे अच्छा सुराग है।

• Commit: job log में लिखा exact SHA। GitHub Actions पर pull-request run target branch में एक temporary merge को टेस्ट करता है, आपकी branch के head को नहीं; यह commit किसी branch पर नहीं होता, इसलिए उसे git fetch origin pull/<number>/merge से fetch करें और जाँचें कि SHA log से मेल खाता है।
• Image और versions: अगर हो तो job की container image, lockfile से dependencies (npm ci, npm install नहीं) और वे browser builds जो आपका Playwright version pin करता है।
• Environment variables: job की non-secret values, CI=true समेत, जिसे कई test configurations पढ़ते हैं; अपने test credentials, production secrets कभी नहीं।
• Time zone, locale और seed: runners अक्सर UTC और English locale में चलते हैं, और random data बनाने वाले tests को अपना seed log करना चाहिए ताकि वही data दोबारा चल सके।
• Subset और order: वही shard और workers की वही संख्या, फिर failing test अकेले और बार-बार, ताकि "अकेले fail होता है" और "सिर्फ़ दूसरे tests के साथ fail होता है" में फ़र्क़ हो सके।

git checkout 9f8e7d6                     # the SHA the job tested
npm ci && npx playwright install --with-deps chromium
export CI=true TEST_SEED=48151           # non-secret values copied from the job
npx playwright test --shard=3/4 --workers=2
npx playwright test invoice.spec.ts --repeat-each=10

Timeouts, fail-fast और re-runs

Timeout का मतलब है कि जिस चीज़ का test इंतज़ार कर रहा था वह हुई ही नहीं: कोई element, कोई response, कोई service। Limit बढ़ाने से यह शायद ही ठीक होता है; call log या trace बताता है कि इंतज़ार किसका था। Limits को परतों में रखें: test timeout (Playwright में default 30 seconds) एक नामित test को fail करता है और report फिर भी लिखी जाती है, जबकि job timeout (GitHub Actions में timeout-minutes, set न हो तो 360 minutes) पूरा job cancel कर देता है और हो सकता है कोई report न छोड़े। Test timeouts को job timeout से काफ़ी नीचे रखें।

Fail-fast पहले failure पर रुक जाता है (Playwright में -x, जो --max-failures=1 का छोटा रूप है); run-all हर failure इकट्ठा करता है। Linting और unit tests जैसे सस्ते शुरुआती stages में fail-fast रखें। महँगे stages और nightly runs में सब कुछ चलाएँ: एक failing test और चालीस failing tests अलग कहानी कहते हैं, और चालीस आम तौर पर environment जैसे किसी साझा cause की ओर इशारा करते हैं। GitHub Actions का matrix एक job fail होने पर बाक़ी jobs cancel कर देता है, जब तक आप fail-fast: false set न करें।

जितना हो सके उतना सीमित re-run करें: सिर्फ़ failed jobs (gh run rerun <run-id> --failed, जहाँ run ID run के URL वाला लंबा नंबर है, उसका # नंबर नहीं) या सिर्फ़ failing test। GitHub Actions का re-run वही commit इस्तेमाल करता है, इसलिए pass होना non-determinism साबित करता है, fix नहीं; इसे सबूत के रूप में दर्ज करें।

Retries और quarantine, संक्षेप में: automatic retry तब run को हरा कर देता है जब कोई flaky test बाद की attempt में pass हो जाए, और quarantine किसी known-flaky test को non-blocking job में ले जाता है जहाँ वह चलता रहता है। दोनों containment हैं, इलाज नहीं: ज़्यादा से ज़्यादा एक retry रखें, "retry पर pass" को flaky रिपोर्ट करें, और हर quarantined test को owner, ticket और deadline दें। Flaky tests guide यह policy समझाती है, और CI/CD testing guide का triage flow दिखाता है कि re-run कहाँ फ़िट होता है।

jobs:
  e2e:
    runs-on: ubuntu-latest
    timeout-minutes: 30      # job limit: cuts off a hang
    strategy:
      fail-fast: false       # one failing shard does not cancel the others
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      # checkout and install steps omitted
      - run: npx playwright test --shard=${{ matrix.shard }}/4

आज़माएँ: YAML फ़ॉर्मेटर

कई pipeline runs में फैले regression का bisect

जब main का कोई scheduled run कई merges के बाद लाल हो जाता है, तो pipeline history आख़िरी green run और पहला red run देती है, दोनों अपने commit के साथ। पहले CI test reports में test की history देखें: जो test हफ़्तों से कभी-कभार fail हो रहा है वह flaky होने का उम्मीदवार है, नया regression नहीं। अगर वह किसी एक run से हर बार fail होता है, तो binary search change ढूँढ लेती है: बीच वाला commit टेस्ट करें, वह आधा रखें जिसमें pass, fail में बदलता है, और दोहराएँ। सोलह candidate commits के लिए ज़्यादा से ज़्यादा चार test runs चाहिए।

git bisect run यह search automate करता है: इसे दी गई command good commit के लिए 0, test न हो सकने वाले commit को skip करने के लिए 125, और bad commit के लिए 1 से 127 तक का कोई दूसरा code देकर exit करती है। Result पर तभी भरोसा करें जब bad commit पर test हर बार fail हो, इसलिए हर step पर उसे दोहराएँ, और जब environment स्थिर रहे। अगर आख़िरी green commit अब भी fail होता है, तो cause code के बाहर है, जैसे runner image, कोई external service या expired test data।

# last green nightly: a1b2c3d     first red nightly: 9f8e7d6
git bisect start 9f8e7d6 a1b2c3d
# TZ=UTC gives the browser the runner's time zone (Linux and macOS)
git bisect run sh -c 'npm ci || exit 125
  TZ=UTC npx playwright test -g "order date" --repeat-each=3'
# git prints "<sha> is the first bad commit"
git bisect reset

Worked example: एक लाल nightly run

Main पर nightly run 412 लाल है; run 411 green था, और बीच में नौ commits हैं। Fail-fast बंद है, इसलिए चारों shards पूरे हुए, और shard 3 में invoice.spec.ts के test "invoice shows the order date" में एक failure है: expected 1 Oct 2026, received 30 Sep 2026। वह पहली attempt और retry दोनों में fail हुआ, इसलिए report उसे flaky नहीं, failed दिखाती है। Trace दिखाता है कि API ने createdAt के रूप में 2026-09-30T22:40:00Z लौटाया, यानी Riyadh में 1 October को 01:40, जो store का time zone है: data सही है और display ग़लत।

Riyadh में tester के laptop पर test pass होता है। Job जैसा ही commit, lockfile, browser build और seed रखने पर एक फ़र्क़ बचता है: runner का browser UTC इस्तेमाल करता है। Playwright का timezoneId UTC पर set करने पर test 10 में से 10 बार fail होता है। Bisect command में TZ=UTC जोड़ने पर, ताकि हर commit runner के time zone में चले, git bisect run से c41d9a0 का नाम आता है, "Format dates with Intl.DateTimeFormat", जिसने store का time zone हटा दिया था। Tester run link, test, trace, reproduction setting और पहले bad commit के साथ product defect दर्ज करता है, और test configuration में timezoneId pin करने का सुझाव देता है ताकि local runs CI जैसा व्यवहार करें।

आज़माएँ: Timezone कन्वर्टर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• GitHub Actions documentationGitHubGitHub Actions में workflows, jobs, runners और artifacts कैसे परिभाषित होते हैं — जहाँ हर push या pull request पर ऑटोमेटेड टेस्ट चलते हैं।
• Reference — GitGit projectहर Git command और उसके options का आधिकारिक reference, काम के अनुसार समूहित — setup, branching, sharing, patching, inspection और debugging।
• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।