Configure Pull Request Flow for SeaLights

Create a Build Session ID for the Pull Request

You create the Pull Request build session ID by using the SeaLights agent with the prConfig option command that requires the following parameters:

The Target branch must have builds already reported to Sealights, otherwise the prConfig command will fail. If your development process includes pull requests merged to features branch, you may want to exclude them from the scope if Sealights analysis or enforce a build to be reported with the creation of the feature branch (via a webhook).

Sample commands

Below are examples of usage of the prConfig CLI command with the Sealights agents.

java -jar sl-build-scanner.jar -prConfig -tokenfile sltoken.txt -appname "MyAppJava" -targetBranch "master" -latestCommit "$MYGH_PR_COMMIT" -pullRequestNumber "807" -repoUrl "https://www.github.com/myappjava/" -pi "*com.example.*"

./node_modules/.bin/slnodejs prConfig --tokenfile sltoken.txt --appname "MyAppjs" --pullRequestNumber "448" --targetBranch "develop" --latestCommit $MYGH_PR_COMMIT --repositoryUrl "https://www.github.com/myappjs/" --proxy "http://proxy2.int" 

SL.DotNet.exe prConfig --appName "myApp.Net" --pullRequestNumber "770" --targetBranch "develop" --latestCommit $MYGH_PR_COMMIT --repositoryUrl "https://www.github.com/myappdotnet/" --includeNamespace myNameSpace.* --buildSessionIdFile buildSessionId.txt

sl-python prConfig --tokenfile sltoken.txt --appname "MyApp.py" --targetbranch "main" --pullrequestnumber "123" --latestcommit $MYGH_PR_COMMIT --repourl "https://www.github.com/mypythonapp/" 

./slcli config create-pr-bsid --app "Myapp.go" --target-branch "main" --pull-request-number "123" --latest-commit $MYGH_PR_COMMIT --repository-url "https://www.github.com/mypgolangapp/"

The parameters packages included for Java and namespace for DotNet should be exactly the same as what was defined to SeaLights for the merged branch so that the compared results will be the same.

Perform a scan and run tests against the PR code

The same SeaLights flow is then configured within the PR context:

• Using the build session ID created in the previous stage, a complete cycle is run on the PR code:

  • Build scan which includes all modules, including the code changes

  • Test executions assigned to the build are run against the code as part of the PR pipeline

See the following documentation for an example on how to configure this for Maven, using a JSON file: Scanning Builds.

Review the results within the PR view in your source control

In order to view the results in line

After performing the pull request, you will be able to view the results inline with your source control within the PR view, denoted with a red diamond:

Drilling down into the “Files Changed” tab, will allow you to see the same red diamond annotation in-line with the changed code and a toolbar summarizing Sealights analytics for this build:

PR Integration with Maven/Gradle plugins

In case you have configured your “regular builds” to be reported using the JSON configuration for Sealights Maven and/or Gradle plugin, you can include dedicated fields and values to support PR configuration.

The following parameters of the configuration file provide PR integration functionality:

Sample JSON for Maven/Gradle plugin

{ 
    "executionType": "full", 
    "tokenFile": "./sltoken.txt", 
    "createPRBuildSessionId": true,
    "appName": "${JOB_NAME}",   
    "repositoryUrl": "https://www.github.com/${JOB_NAME}",
    "pullRequestNumber": "123",
    "latestCommit": "${MYGH_PR_COMMIT}",
    "targetBranch": "master",
    "packagesIncluded": "*com.example.*",   
    "packagesExcluded": "", 
    "filesIncluded": "*.class", 
    "filesExcluded": "*test-classes*", 
    "recursive": true, 
    "includeResources": true, 
    "testStage": "Unit Tests", 
    "proxy": null,
    "logEnabled": false, 
    "logDestination": "console", 
    "logLevel": "warn",
    "sealightsJvmParams": {}
}