Settings functionality encompasses the following elements:
You should use Settings in the following cases:
Create various views for the data based on code tagging/labeling.
Control the data you’d like scope in or out from SeaLights Analysis
Generate/copy/remove token for agent setup to be used automatically or manually or for API integration setup.
Set up the app/branch pairs to be shown in the Test Gap Analytics report.
Configure reports and notifications.
Hide applications from the dashboard.
Settings Screen
To get to the Settings screen click on the settings wheel icon on the top right area of your screen:
You should see the following tabs on the left:
Tokens Management
a. For each token created you can Refresh/Copy/Download/Remove - you should choose either copy or download when you wish to use it in the various setups
b Agent Tokens - you need this token for agent setup as part of setting up your agent (manually or automatically) for scanning builds using the SeaLights Build Scanner or for listening to test executions while using SeaLights Test Listener. The start and end of the token is shown for ease of identification
c. API Tokens - you need this token for setting up an API integration with SeaLights system to SeaLights analyzed data through the Public API
d. Browser Extension Tokens - you need this token for setting up the Sealights Browser extension as indicated below:
Select the SeaLights Chrome Extension icon on the browser bar
Select the 3 dots icon to configure the Browser Extension token
Paste the Chrome Extension token in the box provided
Data Management
Hidden Apps
Choose the Application you wish to Show/Hide (what is visible across the SeaLights dashboard)
Or Click on the App to choose which branches you wish to Show/Hide:
Ignored Code
Use this option whenever you wish to exclude code from SeaLights Analysis. You might want to exclude code that is either auto-generated, getters, setters, default constructors, and other irrelevant code areas such as third party or code you knowingly choose to exclude from the analysis.
The ignoring mechanism can be applied to Auto-Generated code and on a specific area of your code (Classes or Files level).
Ignoring code will remove it from being analyzed for Quality Risks and Coverage.
The auto-generated code is ignored by default, you may change this behavior by unchecking the categories which you like to remain.
Type in the app name and select the relevant app
You may change auto-ignoring by unchecking the categories which you like to remain
Manual Ignoring
Exact match - Ignore a specific file (require the full logical path + filename).
Example:
sl-browser-agent/lib/agent-factory.ts
Starts with - Ignore a folder/class and all of its content. (note, do not use reg expressions)
For example, typing lib will ignore all the files within →
sl-browser-agent/lib/
Ends with - Ignore a file type or common file names.
For example, typing
spec.ts
will ignore all the files which end with*spec.ts
Contains - a wildcard ignore - ignore all files and classes/folders which contains the entered string
Entire app - Ignore the Entire app
Test stage field → Choose “Entire Build”
Condition
Ignoring code works at the file level, not at the method level. Ignoring methods must be managed outside of sealights, ex. workaround to ignore particular methods by refactoring to include them in their own file.
Code Labels
SeaLights allows you to divide your code into areas of interest by defining categories representing either teams (Development, QA, etc), Functional Areas (Login, Reports, etc) or any division you’d like to see within your codebase. Furthermore, under each category, you can define labels that will represent the code area relevant to that label. When using the SeaLights dashboard you can filter your view according to these categories and labels defined here. You can also define labels as “High Priority” so Quality Risks around that label will be highlighted.
Important: The code labels may be applied to The entire application, Classes, Folder, File paths, and Files.
It is highly recommended NOT to apply code labels to the files level as it will not include new files that are added to the Folder/Class.
How to define Categories/Labels:
Click on "Create New Label Rule"
Add a Label Category as highlighted below - Simply provide a Category name
Under a Category, you can add a new label by clicking on “+” and provide a label name
Now you should define the rules that will encapsulate the content you wish to tag/label, click on the label you wish to define on the left, and then pick the relevant code by choosing the app, how to filter it and the path for the code.
Filtering the code, by adding rules:
Exact match - Label a specific file (require the full logical path + filename)
Example:
sl-browser-agent/lib/agent-factory.ts
Starts with - Label a folder/class and all of its content
Example: typing lib will label the highlighted area below →
sl-browser-agent/lib/*.*
Ends with - Label a file type or common file names
Example: typing spec.ts will label all the files which end with spec.ts
Contains - a wildcard labeling - label all files and classes/folders where its name contains the entered string
Entire app - Label the Entire app
Finally, you should decide whether this label represents a “High Priority” code. Once tagged as High Priority - this will be indicated in “red dot” in the dashboard per new quality risks that were found in that high priority code label:
Test Gaps Report Settings
Use these settings to define the Test Gaps Analytics reports - setting the reports here will result in reports that will be available in the Test Gaps Analytics screen.
Adding an application to the Test Gap Analytics
Select the relevant app
Select the relevant branch
Select the start date (a future date - e.g. next Sprint start date or the 1st of the next Month)
Select the reporting period in weeks (Scheduled refresh)
Click "Save"
Note: It takes up to 10 minutes for the new app to appear in the Test Gap Analytics view.
Removing an app from the Test Gap Analytics view can be done by clicking on the delete icon
Notifications
The notifications settings will enable you to push quality notifications to a selected list of attendees.
Notifications are highly effective once combined with proper Quality Gates - Get notified only once your Quality Gates are failing.
How to configure your notification policy?
Select the name of the application
Select the relevant branch
Choose when to be notified
Builds that did not meet the Quality Gates
Builds with Quality Risks
Every completed build
Choose how to be notified by typing in the email address of the relevant attendees (you may send a notification to the Author/Contributor who was working on the code)
Slack
Email
TIA Settings
Please refer to the dedicated documentation to TIA.
Quality Gates
The Quality Gates administration can be found in the "Settings" area and will be permitted to user-admins only.
The Quality Gates screen presents all of your reported applications and will enable to set/modify the Quality gate for All apps / Specific app.
The new functionality helps in setting your quality policy and select the relevant apps that will be part of the policy scope.
Edit Default - Enables to modify the default quality gates
Note - The default value will be applied on new applications only
Apply Default to All - Apply the customer default on all apps (customer default is defined in "Edit Default" section)
Edit a specific app Quality Gate - Click on the pencil icon on the right
Each Quality Cate consists of 4 parameters:
Rule
New/Modified Code Coverage
Overall Code Coverage
Failed Tests
Test Stages
Combined Across Stages
Specific Test Stage (e.g. Unit Tests, Integration Tests...)
Operator (Fixed) - Less than / Greater than
Value - Your quality threshold for the specific rule
Related articles
Filter by label
There are no items with the selected labels at this time.