Sealights identifies the modified/added code and reflects this in the Dashboard on a specific build - compared to its “Reference Build”.
The Reference Build can be, for example, the last build pushed to Production, or the last one promoted to the next branch (e.g. from feature-branch to develop then to main), or the last build from the previous sprint or first build from the current sprint…
Several Sealights analytics are relying on the Reference Build: calculation on modified code and its coverage, identification of Quality Risks, Quality Gates based on modified code…
Different builds can have different reference builds, and Sealights does not allow to modify the Reference Build retroactively for a build already processed. In addition, when you set an old build to be a new Reference build, if there is already a newer build defined as Reference, Sealights will always use the newest Reference and not the latest set ref build. If they want an old build to be ref build, they need to unset all the builds marked as a reference after it
For similar metrics based on date range and aggregation of several builds analytics, please refer to the TGA report.
How to set up manually
By default, the reference build is the previous one and is defined per Branch.
You can identify the current reference build from the reference build column for each application.
When there is a need to change the current reference build, click on the build history of the specific application (by hovering on its build column)
In the build history select the specific build
By hovering on top of the Quality gate column of the specific application click on the “Set reference build” button and approve you want to set it to the previous steps selected build.
This setting will take effect only from the next build.
How to set up via Sealights Public API
In the Sealights platform open “SeaLights API Reference” from the Help menu.
Search for “Set Reference Build” under Builds section. (See
/sl-api/v1/builds/{bsid}/reference)