Retrieve Component BSIDs

Few DevOps mechanisms are available to streamline the work with Sealights' Integration Builds.

Pulling the BSID dynamically from the component

When creating the Integration Build, you’ll query one by one the components deployed in the relevant (and common Testing Lab) to retrieve their BSID.

This option is commonly used when working with containers and orchestration.

Java built with Sealights plugins.

Sealights Maven and Gradle plugins allow to include resource text files to the artefact.

You can extract the buildSessionId.txt file from the Java artefact by using the following command:

java xvf myapp.jar buildSessionId.txt

Node/Javascript

You can extract the Build Session ID of your JS component from the instrumented files using the regular grep command:

cat main.js | grep buildSessionId

The output is "buildSessionId": "89b2477d-fed3-400d-b63f-f1ba133f5080",

Another solution is to copy the buildSessionId file into the instrumented folder when packaging it and read the content of this file to retrieve the unique ID when needed. This solution is often prefered when the application’s JS files are big.

Storing the BSIDs of the components in a central place

A second common solution is to store the buildSessionID of every component in a central place (database, folder component-specific,…) and create the Integration Build from these IDs.

For example, you can use a dedicated Variable Group in AzureDevOps Library section like in the image below:

Using Sealights' Public API

Resolving dynamically the components' details

A third common solution is to use Sealights Public APIs to programmatically retrieve the BSID of every component using specific criteria (the last build, a specific build from a certain date, build matching a certain naming convention…).

Please refer to the Sealights API Reference page for more details, specifically about entry points like:

• /sl-api/v1/slim-builds (Get Builds API)

• or /sl-api/v1/slim-builds/resolve (Resolve Builds API).

Capturing the list of all active agents from a specific environment

Another solution is to take a snapshot of your environment by capturing all the agents up and running from that specific environment at the creation of your Integration Build. This last solution relies on several technical assumptions and is a good starting point but not recommended as a persistent solution.

More details are shared in our dedicated documentation page:Using the list of agents currently active in a specific environment