Skip to content

Bitbucket Pipelines (CI)

TL;DR — Bitbucket Pipelines runs on every PR. Backend: npm ci → lint → build → docker build → coverage report. Frontend: custom pipeline, usually without tests. Coverage is reported via Bitbucket Code Insights (see code-insights.md).

Overview

Continuous Integration runs in Bitbucket Pipelines — triggered on every PR push. The CI layer validates the code; deployment is handled separately in Jenkins (see jenkins-k8s-jobs.md).

Backend microservices pipeline

Typical pipeline for a NestJS / Express backend:

npm ci
npm run lint
npm run build
docker build
(tests run if the repo has them)
Coverage report posted via Bitbucket Code Insights (see code-insights.md)

Key notes: - Runs on every PR before merge. - Coverage is reported via Bitbucket Code Insights — thresholds, env vars, and the merge check are documented in code-insights.md. - Docker builds use --build-arg SECURITIZE_READ_NPM_TOKEN to authenticate private @securitize/* packages. Token is a Bitbucket workspace variable. See secrets.md.

Frontend pipelines

Frontend repos (React MicroFrontends, Vue Control Panel) have their own pipelines:

  • Typically: npm install → npm run build.
  • Tests are typically not part of the frontend CI pipeline — see qa-and-testing.md for context on the frontend testing state.
  • Build output is deployed via Jenkins. Two deploy paths exist depending on the frontend:
  • Modern frontends — Jenkinsfile-UI-SST, deploy via SST/CDK. See frontend-architecture.md.
  • Legacy frontends (e.g. vue-control-panel, securitize-id-fe) — Jenkinsfile-UI, does not use SST/CDK. See the template in ops-manifest.

Test reporting (JUnit XML)

Bitbucket natively picks up JUnit XML test reports and shows a "Tests" tab on the pipeline with failed test names, stack traces, and durations.

  • Setup: add jest-junit as a dev dependency + configure the reporter in Jest config.
  • Output: test-results/junit.xml (auto-detected by Bitbucket).
  • No pipeline YAML changes needed — Bitbucket scans for the XML file automatically.
  • Cost: free (Standard/Premium plans), beta.
  • Limit: max 100 failed tests displayed.
  • Docs: https://support.atlassian.com/bitbucket-cloud/docs/test-reporting-in-pipelines/

Example Jest config: 

"reporters": ["default", ["jest-junit", { "outputDirectory": "test-results", "outputName": "junit.xml" }]]

Node version

Every Bitbucket pipeline declares its Node version at the top of bitbucket-pipelines.yml with the image: directive. This applies to both backend and frontend repos:

image: node:16.17.0

A service repo keeps its Node version in sync across multiple files:

Location Applies to Purpose
.nvmrc at the repo root Backend + Frontend Local dev tooling (nvm use)
bitbucket-pipelines.yml — top-level image: Backend + Frontend Build environment for CI
Dockerfile — FROM node:<version> Backend only (frontends don't have a Dockerfile) Runtime image pushed to ECR

When upgrading Node, update all applicable files in the same PR. For how Jenkins CD resolves the Node version for deploys, see jenkins-k8s-jobs.md (backend) and jenkins-ui-jobs.md (frontend).

Services with migrations on Jenkinsfile-K8S: a 4th file exists off-repo

If the service uses Jenkinsfile-K8S (not Jenkinsfile-K8S-MIG) and has migrations enabled, there is an ephemeral migration Dockerfile hardcoded on each kops server (not in git) with its own FROM node:<version>. Updating .nvmrc, bitbucket-pipelines.yml, and Dockerfile in the PR is not enough — that Dockerfile will still use the old Node version.

You must coordinate with DevOps to update the migration Dockerfile on all 4 kops servers (dev, rc, sandbox, prod). See jenkins-k8s-jobs.md — Option A for context.

For Jenkinsfile-K8S-MIG: no migration Dockerfile on kops servers, but migrations run via nodejs() in Jenkins — which only uses Node versions already installed on Jenkins. If the new version isn't installed, coordinate with DevOps to add it. Same constraint applies to UI pipelines (see jenkins-ui-jobs.md — Build flow, step 3).

Coverage reporting

Coverage is reported as a Bitbucket Code Insights report on the PR. Full detail (env vars, thresholds, the coverage-merge-check Forge app) lives in code-insights.md.

Common failure modes

Symptom Likely cause
404 npm install for @securitize/* NPM token missing or expired. See secrets.md.
Coverage merge check DID NOT PASS Below thresholds. Check COV_IN_TOTAL_THRESHOLD / COV_IN_PATCH_THRESHOLD in code-insights.md.

Canonical Confluence docs

See also

Tags

ci #bitbucket #pipelines #tests #junit #coverage