Connect results to builds and releases

A build records a software version. A release groups the work planned for a delivery. Link test plans to a build so readiness and traceability use the correct execution evidence.

Create a release and a build

record-build.ts

import { createConfiguration, BuildsApi, ReleasesApi } from '@testcollab/sdk';

const config = createConfiguration(process.env.TESTCOLLAB_TOKEN!);
const release = await new ReleasesApi(config).addRelease({
  releasePayload: { project: 123, name: 'October release', status: 'planned' },
});

const build = await new BuildsApi(config).addBuild({
  buildPayload: {
    project: 123,
    version: '2.4.0-rc.1',
    release: release.id,
    environment: 'staging',
    source: 'ci',
    ciProvider: 'github-actions',
    buildUrl: 'https://github.com/example/shop/actions/runs/123',
  },
});

console.log({ releaseId: release.id, buildId: build.id });
// Pass build.id when creating the test plan that will execute this build.

Your CI provider can supply the version, commit and pipeline URL. Keep those values stable for the build your tests actually execute.

Attach the build to a plan

When creating a plan, set the SDK payload’s build field to the build ID. If you also supply a release, use the release that your workflow intends to test.

Do this before execution begins. Once results are recorded, changing the software version associated with the run can make the evidence misleading or be rejected by the API.

Use the CLI in CI

tc createBuild --project 123 --version 2.4.0-rc.1 --environment staging

tc report --project 123 --auto-create --build 2.4.0-rc.1 \
  --format junit --result-file ./results/junit.xml

The CLI can derive build context from supported CI environments. Review tc createBuild --help for overrides such as commit and deployment URL.

Inspect readiness

Use the build traceability and release readiness methods to connect results, defects and coverage to the delivery you are reviewing.