Currents Documentation
Currents.devGitHubChangelog
  • Getting Started
    • What is Currents?
    • Playwright
      • Playwright: Quick Start
      • Troubleshooting Playwright
    • Cypress
      • Your First Cypress Run
      • Integrating with Cypress
        • Compatibility
        • Alternative Cypress Binaries
      • Troubleshooting Cypress
    • Jest
      • Your First Jest Run
      • Detox + Jest
      • Troubleshooting Jest
    • Others
    • CI Setup
      • GitHub Actions
        • Cypress - GitHub Actions
        • Playwright - GitHub Actions
        • Jest - GitHub Actions
        • Node.js - GitHub Actions
        • Commit data for GitHub Actions
        • Custom Docker runners
        • Named Runners
      • GitLab
        • Cypress - GitLab CI/CD
        • Playwright - GitLab CI/CD
        • Custom Docker runners
      • Jenkins
        • Cypress - Jenkins
        • Playwright - Jenkins
      • CircleCI
        • Cypress - CircleCI
        • Playwright - CircleCI
      • Bitbucket
        • Cypress - Bitbucket Pipelines
      • Azure DevOps
        • Cypress - Azure DevOps
        • Playwright - Azure DevOps
      • AWS Code Build
        • Cypress - AWS Code Build
        • Playwright - AWS Code Build
      • NX
        • Playwright - NX
        • Cypress - NX
  • Guides
    • Record Key
    • CI Build ID
    • Reporting
      • Reporting Strategy
      • Reporting in CI
      • Step-Level Reporting
    • CI Optimization
      • Playwright Parallelization
      • Orchestration Setup
      • Fully Parallel Mode
      • Re-run Only Failed Tests
      • Cloud Spot Instances
      • Failing Fast
      • Load Balancing
    • Code Coverage
      • Code Coverage for Playwright
      • Code Coverage for Cypress
    • Currents Actions
      • Setup Currents Actions
      • Using Currents Actions
      • Reference
        • Conditions
        • Actions
    • Playwright Component Testing
    • Playwright Visual Testing
    • Playwright Annotations
    • Playwright Tags
    • MCP Server
  • Dashboard
    • Projects
      • Projects Summary view
      • Project Settings
      • Archive and Unarchive Projects
    • Runs
      • Run Status
      • Run Details
      • Commit Information
      • Tags
      • Run Timeouts
      • Canceling Runs
      • Deleting Runs
      • Run Progress
    • Tests
      • Spec File Status
      • Test Status
      • Flaky Tests
      • Test History
    • Test Suite Explorer
      • Test Explorer
        • Tests Performance
      • Spec Files Explorer
        • Spec Files Performance
      • Errors Explorer
  • Automated Reports
  • Insights and Analytics
  • Administration
    • Email Domain Based Access
    • SSO SAML2.0
      • SAML2.0 Configuration
      • SCIM User Provisioning
      • IdP-initiated Sessions
      • JumpCloud
        • JumpCloud User provisioning
      • Okta
        • Okta User provisioning
      • Troubleshooting SSO
    • Billing & Usage
  • Billing and Pricing
  • Resources
    • Reporters
      • cypress-cloud
        • Batched Orchestration
        • Migration to Cypress@13
      • @currents/cli
      • @currents/playwright
        • Configuration
        • pwc
        • pwc-p (orchestration)
        • Playwright Fixtures
      • @currents/jest
      • @currents/node-test-reporter
      • @currents/cmd
        • currents api
        • currents upload
        • currents cache
        • currents convert
      • Data Format Reference
    • Integrations
      • GitHub
        • GitHub App
        • GitHub OAuth
      • GitLab
      • Slack
      • Microsoft Teams
      • HTTP Webhooks
      • Bitbucket
    • API
      • Introduction
      • Authentication
      • API Keys
      • Errors
      • Pagination
      • API Resources
        • Instances
        • Runs
        • Projects
        • Spec Files
        • Test Signature
        • Test Results
    • Data Privacy
      • Access to Customer Data
      • Data Retention
      • Cloud Endpoints
    • Support
Powered by GitBook
On this page
  • What is CI Build ID?
  • Creating a CI Build ID
  • Automatic Detection
  • Explicit Value
  • Examples
  • Different CI Build ID, Different Builds
  • Same CI Build ID, Different builds
  • Build ID for Popular CI Providers
  • Next Steps
  • FAQ

Was this helpful?

  1. Guides

CI Build ID

Using CI Build ID for reporting to Currents

PreviousRecord KeyNextReporting

Last updated 1 day ago

Was this helpful?

What is CI Build ID?

CI Build ID is a unique identifier used by Currents to collect test results. Think of it as a hard drive "folder". We call it a Run (see Runs).

For example, when multiple CI machines run tests in parallel, their combined results are combined if they use the same CI Build ID.

  • results with --ci-build-id build001 will go to build001 "folder"

  • results with --ci-build-id build002 will go to build002 "folder"

Creating a CI Build ID

You can choose between leveraging our auto-detection algorithm, or manually generating a CI Build ID.

Automatic Detection

Currents automatically detects CI Build ID for popular CI providers based on the presence of environment variables. Please refer to Build ID for Popular CI Providers to see the environment variables used for each provider.

Otherwise, if not explicitly provided, Currents generates a random unique id.

Explicit Value

You can also specify CI Build ID explicitly.

With the CLI, you can use the --ci-build-id flag, for example:

pwc run --ci-build-id CI_BUILD_ID --key xxx --project-id yyy

Example on passing ciBuildId to Playwright Reporter configuration:

// playwright.config.ts
import { currentsReporter } from '@currents/playwright';

//...
reporter: [
  currentsReporter({
    //... 
    ciBuildId: process.env.CURRENTS_CI_BUILD_ID
  }),
]

You can also set the CURRENTS_CI_BUILD_ID environment variable to provide an explicit CI Build ID value.

In order to manually construct a CI Build ID that is unique for each build (but similar across all the parallel machines) it is recommended to use your CI provider's environment variables that combine pipeline/workflow/build identifier and also an attempt number.

For example, for GitHub Actions:

--ci-build-id "${{ github.repository }}-${{ github.run_id }}-${{ github.run_attempt }}"

Refer to your CI provider documentation for the list of available environment variables.

Examples

Different CI Build ID, Different Builds

Imagine a CI pipeline running tests in parallel using multiple machines. Starting two builds with a different CI Build ID will create 2 distinct "Runs" in Currents dashboard.

The reporting will happen for each build independently from the other. That is usually the desired situation - each build should have a unique CI Build ID.

Same CI Build ID, Different builds

In contrast, consider a situation when 2 different builds use the same CI Build ID. That's an uncommon situation, but it's worth demonstrating for understanding the use of CI Build ID.

We created two different builds with the same CI Build ID. That will result in 6 machines reporting their results to the same run.

Build ID for Popular CI Providers

Currents tries to automatically detect the CI provider by looking at the environment variables and picking the best combination.

Build ID for Popular CI Providers Table
Provider
Variables
Fallback

AppVeyor

  • APPVEYOR_PULL_REQUEST_HEAD_REPO_BRANCH

  • APPVEYOR_BUILD_NUMBER

  • APPVEYOR_BUILD_NUMBER

Azure

  • BUILD_BUILDID

AWS Code Build

  • CODEBUILD_BUILD_ID

  • CODEBUILD_SOURCE_VERSION

  • CODEBUILD_BUILD_ID

Bamboo

  • bamboo_buildKey

  • bamboo_buildNumber

  • bamboo_buildKey

Bitbucket

  • BITBUCKET_REPO_SLUG

  • BITBUCKET_BUILD_NUMBER

  • BITBUCKET_BUILD_NUMBER

Buildkite

  • BUILDKITE_BUILD_ID

CircleCI

  • CIRCLE_WORKFLOW_ID

  • CIRCLE_BUILD_NUM

Codeship

  • CI_REPO_NAME

  • CI_BUILD_ID

  • CI_BUILD_ID

Concourse

  • BUILD_ID

  • BUILD_NAME

  • BUILD_ID

CodeFresh

  • CF_BUILD_ID

  • CF_CURRENT_ATTEMPT

  • CF_BUILD_ID

Drone

  • DRONE_PULL_REQUEST

  • DRONE_BUILD_NUMBER

  • DRONE_BUILD_NUMBER

GitHub Actions

  • GITHUB_REPOSITORY

  • GITHUB_RUN_ID

  • GITHUB_RUN_ATTEMPT

  • GITHUB_RUN_ID

GitLab

  • CI_PIPELINE_ID

GoCD

  • GO_REVISION

  • GO_PIPELINE_COUNTER

  • GO_REVISION

Google Cloud

  • REPO_NAME

  • BUILD_ID

  • BUILD_ID

Jenkins

  • BUILD_NUMBER

Semaphore

  • SEMAPHORE_GIT_REPO_SLUG

  • SEMAPHORE_PIPELINE_ID

  • SEMAPHORE_PIPELINE_ID

TeamFoundation

  • BUILD_BUILDID

  • BUILD_BUILDNUMBER

  • BUILD_BUILDID

Travis

  • TRAVIS_REPO_SLUG

  • TRAVIS_BUILD_ID

  • TRAVIS_BUILD_ID

Netlify

  • BUILD_ID

Next Steps

Now, after you're familiar with CI Build ID, explore Reporting Strategy to customizing your reporting to Currents.

FAQ

Retrying builds and CI Build ID

Imagine a situation

  • You start a new build with CI Build ID build-001

    • Build completes and reports all the results to Currents Dashboard

    • Currents marks build-001 as "finished" and all the files as completed

  • You restart the build (attempt B), but keep the same CI build ID build-001

    • Currents considers build-001 as already completed

    • Currents won't accept new results for build-001, because all the results were already reported

    • Currents will not send any new files for Cypress orchestration, because build-001 already ran all the spec files on the first attempt

To resolve this ambiguity, we need to have a different CI build ID for each rerun.

Most CI providers provide a different set of environment variables for different attempts and Currents dashboard can identify it automatically - it will create an entirely new run for retries.

You can also construct an explicit CI Build ID when retrying a build, for example, for GitHub Actions:

"${{ github.repository }}-${{ github.run_id }}-${{ github.run_attempt }}"

If you are generating CI Build ID manually, please make sure to include the retry/attempt identifier.

Please refer to your CI tool documentation to explore what environment variables are available for composing a valid CI Build ID.

Using commit SHA as CI Build ID

Using commit SHA as a CI Build ID is a valid approach and can work for many setups. However, please be aware that rerunning a build with the same commit SHA can result in a duplicate CI Build ID and prevent orchestration and reporting (see #faq-retrying-builds-and-ci-build-id)

How to rerun CI with only failed tests?

See Re-run Only Failed Tests

Creating two distinct runs by using different CI Build ID
A single run is created when using a similar CI Build ID