CI पाइपलाइन में टेस्ट चलाना

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

CI वाली टीम में ज़्यादातर टेस्ट pipeline चलाती है, इसलिए workflow ही तय करता है कि कौन-सा सबूत मौजूद होगा। गलत set चलाने वाला check, या सिर्फ़ Chromium में चलने वाला browser suite, फिर भी हरा दिखता है; और 40 मिनट लेने वाले check का लोग इंतज़ार करना छोड़ देते हैं।

Suite क्या cover करे, यह अक्सर tester तय करता है, इसलिए उसे workflow खुद बदलना आना चाहिए: कोई browser जोड़ना, धीमे suite को nightly run में ले जाना, fail हुए job की report बचाना।

Pipeline file की बनावट

YAML के तीन building blocks हैं। Mapping key: value है; list ऐसी lines हैं जो - से शुरू होती हैं, या छोटा रूप [chromium, firefox]; nesting सिर्फ़ spaces वाले indentation से दिखती है। Indentation में tabs की अनुमति नहीं है, और एक space ज़्यादा या कम key को दूसरे block में पहुँचा सकता है। # के बाद का text comment है, और * से शुरू होने वाली value को quotes में रखना ज़रूरी है, जैसे cron '*/30 * * * *'।

on key triggers की सूची है: pull request खुलने, दोबारा खुलने या उसमें नए commits आने पर pull_request, main तक सीमित push, और cron expression के साथ schedule। Cron के पाँच fields हैं: minute, hour, day of month, month और day of week, इसलिए '0 1 * * *' का मतलब है हर दिन 01:00; schedules default branch पर चलते हैं, और UTC में, जब तक entry में timezone न दिया हो। jobs के नीचे हर job एक runner पर चलता है, यानी वह मशीन जिसका नाम runs-on देता है; GitHub-hosted runner हर job के लिए नई virtual machine है, इसलिए jobs के बीच कुछ नहीं बचता, सिवाय उसके जो आप cache या upload करें। Job के steps एक workspace में क्रम से चलते हैं: uses कोई published action चलाता है, run shell command, और non-zero exit code job को fail कर देता है।

# .github/workflows/e2e.yml
name: e2e

भाग 1:1on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: '0 1 * * *'          # every night, 01:00 UTC

jobs:
  smoke:
    भाग 2:2if: github.event_name != 'schedule'
    भाग 3:3runs-on: ubuntu-latest
    timeout-minutes: 15
    भाग 4:4steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          भाग 5:5cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --project=chromium भाग 6:6--grep @smoke
      - uses: actions/upload-artifact@v7
        भाग 7:7if: always()
        with:
          name: smoke-results
          path: results/
          retention-days: 14

  nightly:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    timeout-minutes: 45
    भाग 8:8strategy:
      fail-fast: false
      matrix:
        browser: [chromium, firefox, webkit]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps ${{ matrix.browser }}
      - run: npx playwright test --project=${{ matrix.browser }}
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          भाग 9:9name: nightly-${{ matrix.browser }}
          path: results/
          retention-days: 14

# .github/workflows/e2e.yml
name: e2e

on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: '0 1 * * *'          # every night, 01:00 UTC

jobs:
  smoke:
    if: github.event_name != 'schedule'
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --project=chromium --grep @smoke
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: smoke-results
          path: results/
          retention-days: 14

  nightly:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    timeout-minutes: 45
    strategy:
      fail-fast: false
      matrix:
        browser: [chromium, firefox, webkit]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps ${{ matrix.browser }}
      - run: npx playwright test --project=${{ matrix.browser }}
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: nightly-${{ matrix.browser }}
          path: results/
          retention-days: 14

आज़माएँ: YAML फ़ॉर्मेटर आज़माएँ: YAML से JSON आज़माएँ: Cron एक्सप्रेशन एक्सप्लेनर

Dependency caching और browser matrix

हर job साफ़ शुरू होता है, इसलिए npm ci हर run में हर package download करेगा। Dependency cache इन downloads को lock file से बनी key के तहत सहेजता है और अगली बार वापस लाता है; package-lock.json बदलने पर key भी बदल जाती है। actions/setup-node पर cache: npm npm का download cache सहेजता है, node_modules नहीं, इसलिए npm ci अब भी ठीक वही install करता है जो lock file कहती है, बस तेज़ी से, और cache न मिलने पर भी नतीजा वही होना चाहिए। Playwright का CI documentation browser binaries cache न करने की सलाह देता है: उन्हें restore करने में लगभग उतना ही समय लगता है जितना download में।

Matrix एक job definition को values के हर combination के लिए एक job में बदलता है। browser: [chromium, firefox, webkit] तीन पैरलल jobs बनाता है, और हर job अपनी value --project को देता है, जो Playwright configuration के किसी project के नाम से मेल खानी चाहिए। shard: [1, 2] जोड़ने से छह jobs बनते हैं, इसलिए नया dimension सिर्फ़ असली risk के लिए जोड़ें, जैसे engines के बीच rendering का अंतर। fail-fast: false हर browser को पूरा चलने देता है, ताकि दिखे कि failure एक engine का है या सबका।

Worked example: pull request या nightly

एक online shop टीम के पास 1,240 unit, 310 API और 180 browser टेस्ट हैं, जिनमें से 25 पर sign-in, search, cart और payment के लिए @smoke tag है। Browser suite हर browser में लगभग 35 मिनट लेता है; pull requests का budget 15 मिनट है। टीम हर suite को उसकी speed, stability, उसके cover किए risk और fail होने पर कार्रवाई करने वाले के आधार पर छाँटती है। ऊपर का workflow browser वाली rows लागू करता है।

• Pull requests को अहम journeys पर तेज़ और stable checks मिलते हैं; लेखक इनका इंतज़ार करता है, इसलिए ये merge को रोकते (gate) हैं।
• main पर push वही set दोहराता है: अलग-अलग pass हुए दो pull requests मिलकर टूट सकते हैं।
• Nightly run धीमे और व्यापक suites संभालता है; एक तय owner हर सुबह उसे पढ़ता है और पिछली हरी रात के बाद के commits जाँचता है।
• Quarantined flaky टेस्ट pull request set से बाहर होकर सिर्फ़ रात में चलते हैं, और किसी को रोके बिना report करते हैं। Nightly job में main test step --grep-invert @quarantine जोड़ता है, जो उस tag वाले टेस्ट छोड़ देता है; दूसरा step --grep @quarantine को continue-on-error: true के साथ चलाता है, ताकि उसका fail होना job को fail न करे, और if: always() के साथ, ताकि main step fail होने के बाद भी वह चले।

Suite                 Tests    Time*   Pull request  Push to main  Nightly 01:00 UTC
Lint + unit           1,240    3 min   gate          run           run
API tests             310      6 min   gate          run           run
E2E @smoke, Chromium  25       4 min   gate          run           -
E2E full, 3 browsers  3 x 180  35 min  -             -             run, 3 parallel jobs

gate: must pass before the merge
*  wall-clock time per job; illustrative figures

आज़माएँ: Cron एक्सप्रेशन जनरेटर

Test reports, artifacts और पैरलल jobs

Test runner को मशीनों और लोगों के लिए नतीजे लिखने के लिए configure करें, फिर पक्का करें कि job उन्हें बचाए। नीचे का excerpt CI server के लिए JUnit XML, लोगों के लिए HTML report, और fail हुए टेस्ट के traces और screenshots लिखता है। GitLab XML को artifacts:reports:junit से पढ़ता है, Jenkins JUnit plugin के junit step से; बाकी जगह platform का documentation देखें।

Artifacts वे files हैं जिन्हें job upload करता है ताकि वे runner के बाद भी बचें। इन्हें if: always() के साथ upload करें: default रूप से fail हुए step के बाद का step skip होता है, और ज़रूरत fail हुए runs में ही पड़ती है। GitHub Actions में artifact के नाम एक run में unique होने चाहिए, इसीलिए nightly-${{ matrix.browser }}; retention-days तय करता है कि वे कितने दिन रहें। Personal data और secrets इनसे बाहर रखें।

जिन jobs में needs नहीं है वे पैरलल चलते हैं, matrix jobs भी, जितने runners उपलब्ध हों; max-parallel matrix की सीमा तय करता है। Job के अंदर Playwright की CI guidance stable runs के लिए एक worker पसंद करती है, और फैलाव shards से। हर job की reports merge करें, जैसे Playwright के blob reporter और npx playwright merge-reports से, ताकि gate एक ही नतीजा देखे।

// playwright.config.ts (excerpt)
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  workers: process.env.CI ? 1 : undefined,
  outputDir: 'results/artifacts',                       // traces, screenshots
  reporter: [
    ['junit', { outputFile: 'results/junit.xml' }],                // for the CI server
    ['html', { outputFolder: 'results/html', open: 'never' }],     // for people
  ],
  use: { trace: 'retain-on-failure', screenshot: 'only-on-failure' },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
  ],
});

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

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

संदर्भ

• GitHub Actions documentationGitHubGitHub Actions में workflows, jobs, runners और artifacts कैसे परिभाषित होते हैं — जहाँ हर push या pull request पर ऑटोमेटेड टेस्ट चलते हैं।
• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।
• YAML Ain't Markup Language (YAML™) version 1.2.2YAML.org · 2021YAML 1.2 का डेटा मॉडल और सिंटैक्स, और JSON से उसका संबंध (हर JSON दस्तावेज़ वैध YAML 1.2 है)।
• Unit test reports — GitLab CI/CDGitLabJUnit XML नतीजों को pipeline artifact के रूप में प्रकाशित करना ताकि फ़ेल टेस्ट merge request में दिखें और रनों के बीच तुलना हो सके।