Phase 3: Continuous Coverage

Prerequisite: You have completed Phase 2: Advanced Coverage Analytics

Overview

In this phase, you'll integrate SeaLights into your CI pipeline. This enables continuous collection and reporting of coverage information as a streamlined part of your build and test processes.

For example, if your CI pipeline runs unit tests, functional test suites, or any other automated tests as part of the build flow, completing this step allows SeaLights to automatically capture their coverage and display it in the SeaLights dashboard and reports.

Optionally, you can also configure SeaLights to integrate with your source control management (SCM) system. This provides deeper insights, such as identifying the developers who contributed to untested code changes and enabling the SeaLights browser extension to highlight untested modified code directly in your source files.

What You'll Get

• Continuous coverage collection — Coverage data is captured automatically as part of your CI process, rather than manually

• Complete code coverage including unit tests — Capture coverage from all automated tests in your pipeline

• CI and source control integration — Connect SeaLights to your build and SCM systems for richer insights

Implementation Steps

Follow these steps to add SeaLights to your CI pipeline.

Prerequisite: Your application is already set up to run with SeaLights as a javaagent, per the instructions in previous phases.

1

Download the SeaLights Java Agent

You have previously downloaded the SeaLights Java agent for use by your Test Runners (Phase 2). Now you will need the SeaLights Java Agent to be available during the build step in your CI pipeline.

Download the latest version of the SeaLights Java Agent.

There are two agent files

• Build Scanner - sl-build-scanner.jar

• Test Listener - sl-test-listener.jar

These agent files can be downloaded from: https://agents.sealights.co/sealights-java/sealights-java-latest.zip

Example CLI commands for downloading the SeaLights Java Agent:

# Download the latest Java agent
wget -nv https://agents.sealights.co/sealights-java/sealights-java-latest.zip

# Extract the agent
unzip -oq sealights-java-latest.zip

Instructions for downloading a specific version of the agent can be found here

Note: You will also need a valid SeaLights Agent Token, as explained in the Prerequisites

2

Configure the Agent & Generate a Build Session ID

This step configures the agent and generates a Build Session ID (BSID) that uniquely identifies this build in the SeaLights system, using the command java -jar sl-build-scanner.jar -config [options]

Example Configuration Command:

java -jar sl-build-scanner.jar -config \
-tokenfile /path/to/sltoken.txt \
-appname <component-name> \
-branchname <component-branch-name> \
-buildname <component-build-number> \
-packagesincluded "*com.company.*"

Minimum Required Parameters for this command:

• -tokenfile - Path to the agent token file. Note: The token can also be placed in a file named sltoken in the same directory as the agent. In that case, this parameter is not required.

• -appname - The name of your component. This name will appear in the SeaLights dashboard and reports. This can be any name that represents your component.

• -branchname - Git branch name

• -buildname - A unique identifier that represents the current build of your component — for example, the CI build number, a timestamp, or a custom name (as long as it is unique).

• -packagesIncluded - A comma-separated list of packages composing the application. Specifies which Java packages SeaLights should monitor for coverage. By default, SeaLights may analyze all packages, but explicitly setting this improves performance.

What this command generates:

• buildSessionId.txt - this file contains your BSID, a unique identifier linking this build to SeaLights. By default, this file is created in the current working directory.

• Console Output - Confirmation of successful configuration and the generated BSID

3

Scan Your Component

This step analyzes your project structure using the command java -jar sl-build-scanner.jar -scan [options]

The scan results are uploaded to SeaLights and used as the baseline for calculating and displaying coverage information for that specific component build.

You can perform the scan either by running the SeaLights agent directly from the CLI, or by integrating it with your build tool (such as Maven or Gradle) using the SeaLights Maven or SeaLights Gradle plugins.

Minimum Required Parameters for this command:

• -tokenfile - Your SeaLights authentication token or path to token file

• -buildsessionidfile - Path to the file containing the unique Build Session ID (created in the previous step)

• -workspacepath - Path to the source workspace

• -filesIncluded - A comma-separated list of the files to include in the scan

Command:

java -jar sl-build-scanner.jar -scan \
-tokenfile /path/to/sltoken.txt \
-buildsessionidfile buildSessionId.txt \
-workspacepath "/path/to/war/files" \
-filesincluded "*.war"

Multi Module Projects

If you want to report separate parts of the application as separate modules within the same component, you can do so with the -moduleName option.

Command:

This command must be run on each individual module you want to report. It is important to always use the exact same module names each time you report a new build of your component.

java -jar sl-build-scanner.jar -scan \
-tokenfile /path/to/sltoken.txt \
-buildsessionidfile buildSessionId.txt \
-workspacepath "/path/to/war/files" \
-filesincluded "*.war" \
-moduleName "module1"

When you finish scanning each module, you need to notify SeaLights that your build is completed with the buildEnd option, along with the result of your build (either -ok or -failed depending on the result of your build.

java -jar sl-build-scanner.jar \
-buildend -ok \
-tokenfile sltoken.txt \
-buildsessionidfile buildSessionId.txt

Additional optional parameters may be found here: Java Agent Configuration Parameters

What happens when the scan runs:

• The component—along with its specified build number—will appear immediately in the SeaLights dashboard, indicating a successful connection between the agent and SeaLights.

• Your command line will show a clear indication about the folders being scanned.

• Success or error messages will appear during the scan and upon its completion.

Output: The command will show progress as it processes files. You'll see output indicating which files are being scanned.

The agent will automatically use a .git directory it finds in the repo and it defaults to Github. This means Github links will be shown on the SeaLights dashboard automatically.)

If you are using a different SCM, there are 3 other parameters that must be set to see the links on your SeaLights dashboard. This is entirely optional — you do not need to configure SCM details to get full coverage data with SeaLights.

4

Continue With Your Deployment and Testing

No additional changes are necessary at this point.

Once you've made these changes to the Build Step in your CI, you can trigger a full deployment run (build, deploy, test). SeaLights was added to the deployed component in Phase1; to the test runners in Phase 2; and in this Phase, it has been added to your build stage.

ALTERNATIVE APPROACH: Using the SeaLights Build Tool Plugins

SeaLights provides plugins for both Maven and Gradle, allowing you to integrate it into your CI pipeline even more seamlessly. These plugins take the place of the above steps.

Instructions for each plugin can be found:

• ALTERNATIVE: Maven Plugin

• ALTERNATIVE: Gradle Plugin

To confirm that Phase 3 was successful:

1. Check the console output — Look for messages confirming successful agent startup and scan completion.

2. Visit the SeaLights Dashboard — Verify that:

   1. Your component's build name appears with the name you have given it in the configuration file

   2. Coverage data is correctly reflected in the test stage

If this new test stage reflects coverage under your component, Phase 3 is complete!

---

Next Steps

With Continuous Coverage in your CI now in place, you can move to Phase 4: Test Impact Analysis. In Phase 4, you'll begin using TIA to execute the smallest subset of tests — without compromising quality.