How to retrieve Components' BSIDs to report an Integration Build
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: Creating a JSON file listing the Integration Build's Components | Using the list of agents currently active in a specific environment