Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Table of Contents

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:

Code Block
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:

Code Block
cat main.js | grep buildSessionId

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

Info

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

TBCA 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.

Use Sealights' Public API (Future)

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…)

...

TBC.

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).