Belajar Playwright - CI/CD Integration

#Pendahuluan

Test yang hanya berjalan di laptop adalah test yang bisa diabaikan. Episode 14 ini membawa suite kalian ke CI/CD — menjalankan test secara otomatis di setiap commit, memproduksi artifact yang bisa ditinjau, dan memberikan feedback cepat kepada tim.

CI adalah lingkungan yang berbeda dari lokal: headless, tanpa input manusia, dan sering berjalan paralel. Episode ini membahas pola integrasi yang terbukti untuk GitHub Actions, GitLab CI, Jenkins, dan Azure Pipelines, termasuk cara menangkap artifact test dan menjalankan matrix untuk banyak browser sekaligus.

#Integrasi ke GitHub Actions

#Workflow Dasar

GitHub Actions adalah pilihan paling mudah karena Playwright menyediakan action resmi:

name: End-to-End Tests
 
on:
  push:
    branches: [main, staging]
  pull_request:
 
jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - uses: actions/install-playwright@v1
        with:
          browsers: chromium,firefox,webkit
      - run: npm ci
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-artifacts
          path: test-results/
          retention-days: 7

actions/install-playwright@v1 menginstall browser binaries dengan cache otomatis. upload-artifact berjalan hanya saat gagal (if: failure()) untuk menyimpan test-results — trace dan screenshot tersedia untuk ditinjau setelah pipeline merah.

#Deployment Service di GitHub Actions

Untuk test yang butuh aplikasi berjalan, gunakan webServer di konfigurasi Playwright — CI akan menunggu server siap sebelum menjalankan test:

webServer di konfigurasi

export default defineConfig({
  webServer: {
    command: 'npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});

webServer otomatis meluncurkan aplikasi, menunggu URL siap, lalu menutupnya setelah suite selesai. Dengan ini, CI tidak perlu mengelola proses server secara manual.

#GitLab CI, Jenkins, dan Azure Pipelines

#GitLab CI

GitLab CI memakai Docker image resmi Playwright yang sudah berisi semua dependencies browser:

stages:
  - test
 
e2e:
  stage: test
  image: mcr.microsoft.com/playwright:v1.53.0
  script:
    - npm ci
    - npx playwright test
  artifacts:
    when: always
    paths:
      - playwright-report/
      - test-results/
    expire_in: 7 days

mcr.microsoft.com/playwright:v1.53.0 adalah image resmi yang berisi Node.js, browser, dan dependencies sistem. GitLab menyimpan artifact dengan artifacts.when: always agar report tersedia bahkan saat test sukses.

#Jenkins dan Azure Pipelines

Di Jenkins, pola yang sama ditulis sebagai pipeline file: npx playwright install --with-deps lalu npx playwright test, dan artifact diarsipkan lewat archiveArtifacts. Azure Pipelines menggunakan langkah serupa dengan task PublishTestResults atau mekanisme publish artifacts bawaan.

#Headless vs Headed Runs di CI

#Selalu Headless di CI

CI tidak memiliki display, jadi test harus dijalankan headless. Ini sudah menjadi default Playwright:

npx playwright test

Secara default Playwright berjalan headless di CI dan headed di lokal ketika memakai --headed. Untuk memastikan konsistensi, set headless: true secara eksplisit di konfigurasi CI atau biarkan default yang sudah benar.

#Kapan Butuh Headed

Mode headed di CI berguna untuk debug sementara — misalnya saat memeriksa perilaku yang hanya muncul dengan GPU. Namun untuk alur normal, headless lebih cepat dan memakai resource lebih sedikit.

#Test Artifacts: Traces, Videos, Screenshots

#Konfigurasi Artifact untuk CI

Aktifkan artifact secara selektif di CI agar penyimpanan efisien:

Config artifact untuk CI

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  use: {
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'on-first-retry',
  },
});

trace: 'on-first-retry' menghasilkan trace saat test gagal pada percobaan pertama dan lolos pada retry — menangkap flakiness yang biasanya sulit direproduksi. Video dan screenshot hanya dipertahankan untuk test yang gagal.

#Meninjau Artifact dari CI

Setelah pipeline selesai, unduh artifact dan buka report dengan:

npx playwright show-report playwright-report/

npx playwright show-report playwright-report/ menampilkan report yang diunduh dari CI. Report ini memuat trace viewer, screenshot, dan video untuk setiap test yang gagal — informasi lengkap untuk debugging tanpa menjalankan ulang apa pun.

#Parallel Test Execution dan Matrix Runs

#Paralelisme Bawaan

Playwright menjalankan test secara paralel secara default — beberapa worker memakai beberapa proses sekaligus. Atur jumlah worker di konfigurasi atau CI:

npx playwright test --workers=4

--workers=4 membatasi eksekusi ke 4 proses paralel. Di CI, sesuaikan dengan resource runner — terlalu banyak worker justru memperlambat karena saling berebut CPU dan memori.

#Matrix Runs untuk Banyak Browser

Dengan GitHub Actions matrix, setiap kombinasi browser menjadi job terpisah yang bisa dijalankan di runner berbeda:

strategy:
  matrix:
    browser: [chromium, firefox, webkit]
steps:
  - run: npx playwright test --project=${{ matrix.browser }}

--project=${{ matrix.browser }} memfilter eksekusi ke satu project per job. Matrix memberi isolasi resource antar browser dan memungkinkan laporan per-browser yang lebih jelas.

#Penutup

Episode 14 mengirim suite kalian ke pipeline produksi: GitHub Actions dengan action resmi dan artifact upload, GitLab CI dengan image Docker resmi, Jenkins dengan archive, dan Azure Pipelines — semuanya dengan prinsip yang sama: headless run, artifact selektif untuk failure, dan matrix runs untuk memperluas coverage browser.

Inti yang harus dibawa pulang:

• Gunakan action atau image resmi Playwright agar browser terinstall di CI.
• webServer membuat CI meluncurkan dan menunggu aplikasi secara otomatis.
• Artifact screenshot, video, dan trace ditangkap hanya untuk test yang gagal.
• Headless adalah default dan pilihan yang tepat untuk CI.
• Matrix runs menjalankan per-browser di job terpisah untuk feedback yang jelas.

Di episode 15 selanjutnya kita akan membahas speed dan reliability optimization — mengoptimalkan runtime dan paralelisme, reuse contexts dan fixtures dengan selective retries, mengurangi flaky tests lewat stable locators, serta memakai test.fixme dan test.skip secara strategis.