Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »

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.

  1. Type in the app name and select the relevant app

  2. You may change auto-ignoring by unchecking the categories which you like to remain

  3. Manual Ignoring

    1. Exact match - Ignore a specific file (require the full logical path + filename).

      • Example:  sl-browser-agent/lib/agent-factory.ts

    2. 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/

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

    4. Contains - a wildcard ignore - ignore all files and classes/folders which contains the entered string

    5. Entire app - Ignore the Entire app

    1. Test stage field → Choose “Entire Build”

    2. 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:

  1. Click on "Create New Label Rule"

  2. Add a Label Category as highlighted below - Simply provide a Category name

  3. Under a Category, you can add a new label by clicking on “+” and provide a label name

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

  5. Filtering the code, by adding rules:

    1. Exact match - Label a specific file (require the full logical path + filename)

      • Example:  sl-browser-agent/lib/agent-factory.ts

    2. Starts with - Label a folder/class and all of its content

      • Example: typing lib will label the highlighted area below → sl-browser-agent/lib/*.*

    3. Ends with - Label a file type or common file names

      • Example: typing spec.ts will label all the files which end with spec.ts

    4. Contains - a wildcard labeling - label all files and classes/folders where its name contains the entered string

    5. Entire app - Label the Entire app

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

  1. Select the relevant app

  2. Select the relevant branch

  3. Select the start date (a future date - e.g. next Sprint start date or the 1st of the next Month)

  4. Select the reporting period in weeks (Scheduled refresh)

  5. 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?

  1. Select the name of the application

  2. Select the relevant branch

  3. Choose when to be notified

    1. Builds that did not meet the Quality Gates

    2. Builds with Quality Risks

    3. Every completed build

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

    1. Slack

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


















  • No labels