CI, Git and debugging · Reproducible quality evidence

The 60-second model#

CI executes reproducible checks for a change and preserves results; a gate matters only if its failures block the relevant workflow. Git tracks changes and supports review. Debugging separates product defects from automation, data and environment failures using evidence. The JD asks for CI/CD contribution and Git, not a confirmed GitLab/Jenkins implementation.

A practical pipeline#

# Illustrative GitLab CI, not OMNO's confirmed platform.
stages: [test]
qa:
  image: node:22-bookworm
  stage: test
  script:
    - npm ci
    - npx tsc --noEmit
    - npm run lint
    - npx playwright install --with-deps chromium
    - npx playwright test --project=chromium
  artifacts:
    when: always
    paths: [playwright-report/, test-results/]
    reports:
      junit: reports/junit.xml
    expire_in: 7 days
  allow_failure: false

Assumes actual package scripts, reporter config, sandbox credentials and approved network access. Pin an approved runtime/image digest in real CI; browser installation uses the locked package version. Never include playwright/.auth files or token-bearing dumps in artifacts. Jenkins concepts transfer: agents/runners, stages/jobs, credentials, archived reports and failing build status.

allow_failure: true allows a failed GitLab job without failing the pipeline. Critical checks normally need false plus project settings requiring successful pipelines/protected review. An optional experiment is different from quietly making a critical payment check nonblocking. Exact merge controls depend on the platform/project.

Workers, shards and retry#

# Separate GitLab parallel jobs, if configured, partition the suite.
npx playwright test --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
# This controls worker concurrency inside ONE run.
npx playwright test --workers=2

Shards have separate workspaces but may share backend accounts/configuration. Provision safe data across all concurrent pipelines/jobs/workers. Retries can capture diagnostic evidence but do not fix shared sessions, races or duplicate financial writes. Classify a runner outage separately from a real application failure before retrying an entire job.

Git workflow and review#

git status
git switch -c qa/payment-refund-boundaries
git diff
git add tests/api/refund.spec.ts
git diff --cached
git commit -m "Test refund amount boundaries"
git push -u origin qa/payment-refund-boundaries

Commands illustrate a feature branch with intentionally staged files. A commit is local; push updates a remote. Review untracked and staged changes so tokens/auth state/test artifacts do not slip into a commit. Pull updates must respect the team's merge/rebase policy. Fetch updates remote refs without itself merging your branch.

For a conflict, understand both intended behaviors, edit the coherent combined change, remove conflict markers, run relevant tests and review the diff before continuing. Do not resolve payment assertions by choosing whichever side makes CI green. Avoid rewriting shared history unless the team workflow explicitly permits it.

Review tests for requirement relevance, strong assertions, isolated fixtures, proper await/error handling, stable locators, cleanup and safe artifacts. Link Jira acceptance criteria to test identity, CI result and defect. Case counts and pass rate do not prove requirement coverage.

Evidence-first investigation#

1. Capture build/commit, exact command, browser/runtime, worker/shard, account/configuration and payment/correlation identity.
2. Inspect failure/stack and the trace's last successful action, DOM and network.
3. Follow the same operation into authorized service/provider/event evidence.
4. Form competing hypotheses, reproduce the relevant CI conditions and change one variable.
5. Apply a targeted fix, then repeat the original workload and monitor recurrence.

npx playwright test tests/ui/payment.spec.ts --workers=1 --repeat-each=10
npx playwright show-report
npx playwright show-trace test-results/example/trace.zip

One worker improving the result narrows hypotheses; it does not prove CPU was the cause. A shared account also becomes less contested. Compare local/CI time zone, browser/OS, fonts, resources, routing config and service availability with evidence. Headless mode is not a universal explanation.

Worked scenario: intermittent payment timeout#

Hypothetical CI test passes alone but fails when four jobs run. The trace shows a redirect to login after another job authenticates with the same merchant account. Provider requests never start in the failing test. This evidence points to session invalidation, not slow PSP processing.

Fix: independent leased/provisioned account per conflicting scope, fresh verified auth in each job, and a dedicated account for password/deactivation tests. Verify across the original parallel jobs and an overlapping pipeline. Retain a failure timeline and observed run counts; do not invent a percentage improvement. If remaining failures show actual pending processing, investigate those separately instead of claiming every timeout has one cause.

Release-risk communication and answer#

Report what failed, which business risk is unproven, confidence in the cause, safe workaround/replacement evidence, owner and next step. Quarantine requires tracked issue, expiry, risk acceptance and replacement coverage; test.skip removes coverage. A critical duplicate-charge risk should not disappear behind optional CI status.

30 seconds: “I make tests reproducible through lockfiles, isolated data, required checks and useful artifacts. For failures I follow a trace/correlation timeline and separate application, test, data and environment causes. I use Git branches/review to keep changes understandable and report missing release confidence clearly.”

Memory hook: preserve evidence before changing timing. References: Playwright CI, Trace Viewer, GitLab YAML, Git documentation. Next: hands-on exercises.

Quick practice#