Definition
- Pipeline trigger – Starts on Git commit or pull request to a watched branch.
- Setup – Install dependencies from lockfile for reproducibility, install browser binaries, cache both.
- Execution – Run tests in parallel with per-environment config (BASE_URL, secrets from vault).
- Artifacts – Collect screenshots, videos, and traces on failure for diagnosis.
- Reporting – Publish HTML or Allure report as a hosted page or attached artifact.
- Secrets – Stored in the CI platform's secret store, injected at runtime, masked in logs, never committed.
Integrating the National Bank of India tests into CI is like setting up a fully automatic night shift that checks the whole bank after every change. The moment a developer commits, the pipeline wakes up, gathers the tools and the browsers, splits the work across several machines, runs all the checks against the right environment, keeps photos and videos of anything that failed, posts a tidy report on the board, and pings the team if something broke. And the sensitive things, like the test login password and the environment addresses, are kept in a locked safe and handed to the pipeline only at run time, never written into the scripts or the logs where anyone could read them.
Understanding the Concepts
What triggers the pipeline?
On a Git commit or pull request to a watched branch, the CI platform starts a workflow.
# .github/workflows/e2e.yml
name: E2E Tests
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
How do you install dependencies and browsers?
Install deterministically from the lockfile and cache between runs.
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npx playwright install --with-deps chromium
How do you run tests in parallel?
Use Playwright's built-in workers or shard across multiple CI jobs.
# Option 1: Playwright workers on one machine
- run: npx playwright test --workers=4
# Option 2: Shard across CI jobs
strategy:
matrix:
shard: [1/4, 2/4, 3/4, 4/4]
steps:
- run: npx playwright test --shard=${{ matrix.shard }}
How do you configure per-environment settings?
Set base URL and related variables per environment.
env:
BASE_URL: ${{ vars.STAGING_URL }}
TEST_USER: ${{ secrets.TEST_USER }}
TEST_PASS: ${{ secrets.TEST_PASS }}
// playwright.config.ts reads from env
use: {
baseURL: process.env.BASE_URL || 'http://localhost:3000',
}
How do you collect artifacts?
Upload screenshots, videos, and traces so CI failures are diagnosable.
- name: Upload test artifacts
uses: actions/upload-artifact@v4
if: always()
with:
name: test-results
path: test-results/
- name: Upload report
uses: actions/upload-artifact@v4
if: always()
with:
name: playwright-report
path: playwright-report/
How do you publish reports and notify?
Publish an HTML or Allure report and send failure notifications.
- name: Publish Allure Report
if: always()
run: npx allure generate allure-results -o allure-report
- name: Notify on failure
if: failure()
run: |
curl -X POST "$SLACK_WEBHOOK" \
-d '{"text":"E2E tests failed. Report: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"}'
How do you handle secrets securely?
Secrets are stored in the CI platform's secret store, injected at runtime, and masked in logs.
DO:
- Store in GitHub Secrets / Azure Key Vault / Jenkins Credentials
- Inject as env vars at runtime
- CI platform automatically masks them in logs
DO NOT:
- Commit to repository (even .env files)
- Echo in scripts (curl, printf)
- Use in test names or assertions that print to logs
# Scoping: use different secrets per environment
jobs:
test-staging:
environment: staging
env:
TEST_USER: ${{ secrets.STAGING_TEST_USER }}
test-production:
environment: production
env:
TEST_USER: ${{ secrets.PROD_TEST_USER }}
What is the complete pipeline?
The full pipeline from commit to notification.
name: E2E Pipeline
on: [push, pull_request]
jobs:
e2e:
runs-on: ubuntu-latest
env:
BASE_URL: ${{ vars.STAGING_URL }}
TEST_USER: ${{ secrets.TEST_USER }}
TEST_PASS: ${{ secrets.TEST_PASS }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 20, cache: npm }
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test --workers=4
- uses: actions/upload-artifact@v4
if: always()
with: { name: results, path: test-results/ }
- uses: actions/upload-artifact@v4
if: always()
with: { name: report, path: playwright-report/ }
What are common interview follow-up questions?
- "How do you gate the merge on test results?" Configure the CI job as a required status check on the branch protection rule.
- "How do you handle flaky tests in CI?" Use limited retries as a temporary net, track the retry rate, and fix the root cause.
- "What if CI is slow?" Cache dependencies and browsers, shard across parallel jobs, and use Playwright's built-in workers.
Key Takeaway
My end-to-end CI integration turns the suite into an always-on quality gate. It triggers on a Git commit or pull request to a watched branch. The first stages make the environment reproducible and fast: a clean install from the lockfile with dependency caching, then installing the Playwright browsers with their operating-system dependencies, because browser automation needs real browsers on the runner. The test stage runs with per-environment configuration, setting the base URL and related variables so the same suite targets development, QA, staging, or production, and it parallelizes, either Playwright's internal workers on one machine or sharding across several parallel CI jobs for a large suite, with the slices merged. Throughout, I configure diagnostics on failure, screenshots, videos, and a Playwright trace. After the run I collect those artifacts and upload them so they persist beyond the ephemeral runner, publish a human-readable HTML or Allure report, and send failure notifications to chat, email, or a pull-request status check with a link to the report, and I gate the merge on a green result so broken changes do not land.
Handling secrets securely is a first-class concern, especially for a bank. I never commit credentials, tokens, or sensitive URLs into the repository. I store them in the platform's secret store, GitHub encrypted secrets, Azure DevOps secret variables or a variable group backed by a key vault, or Jenkins credentials, and I inject them as masked environment variables at run time so they are not printed in logs, and I never echo them myself. I scope secrets to the minimum needed, use separate credentials per environment, and prefer short-lived or vault-issued credentials, while keeping non-secret environment configuration like the QA base URL in ordinary variables, separating what is sensitive from what is merely variable.
At the National Bank of India I built exactly this in GitHub Actions and mirrored it in Jenkins. Every commit ran the suite sharded across four parallel jobs against staging, uploaded report, traces, and videos on every run including failures, published the HTML report, and posted a Slack alert with a link when anything failed, and we blocked merges on red. The test login lived in the encrypted secret store and was masked in logs, never in the repo. The payoff was that regressions were caught on every change with a diagnosable trail, and an on-call engineer could open the trace from the artifacts instead of rerunning. Being able to walk the pipeline stage by stage and, crucially, to explain secret handling as injected-at-runtime and masked rather than committed is what shows an interviewer I can operate automation safely in a real banking CI/CD, not just run it on my laptop.
Remember one sentence: a CI pipeline should install, run in parallel with per-environment config, collect trace artifacts, publish reports, notify on failure, and gate merges, with secrets injected from the vault and never committed.
---
Visual Overview
CI Pipeline for Automation Suite
─────────────────────────────────
Git commit / PR
│
┌────▼─────────────────┐
│ Install dependencies │ npm ci (from lockfile)
│ Install browsers │ npx playwright install
└────┬─────────────────┘
│
┌────▼─────────────────┐
│ Run tests │ Parallel workers or shards
│ Per-env config │ BASE_URL from env vars
│ Secrets from vault │ TEST_USER, TEST_PASS
└────┬─────────────────┘
│
┌────▼─────────────────┐
│ Collect artifacts │ Screenshots, videos, traces
│ Publish report │ HTML / Allure
└────┬─────────────────┘
│
┌────▼─────────────────┐
│ Notify on failure │ Slack / email with link
│ Gate merge │ Block if red
└──────────────────────┘