Auto status

Catalog tasks are one of the primary ways for catalog administrators to decide what open source packages are allowed to be used. However, manually working through the task list can be overwhelming. With auto status, the decision making process is simplified so that you only have to review tasks for what you care about.

Standards configuration

Prior to auto status, when you enabled a standard, every violation created a task and a decision wasn't made about a package until all related tasks were completed. Now you can choose how you want standards violations handled.

Enabled standard

When you enable a standard, Tidelift checks releases for violations of this standard. By default, administrator review is not required (meaning a task is not created), and packages with violations will be denied.

Create a task

When this is enabled, a task will be created when violations are found. You can then choose to keep or override the decision the system made for you.

Allow the use

When this is enabled, Tidelift won’t deny the release due to violations of the standard. The violation will be allowed for the release and Tidelift will track the violation in your catalog.

Tasks

With auto status set up, the status of a package no longer rests on task completion. The only tasks created are for reviewing the automatic decision that was made, and then deciding if you want to change the decision manually. Manual changes to automatic decisions are called overrides.

Overrides

While override creation will be primarily through task completion, overrides can be created on any violation, even if administrator review is not required on standard configuration. 

Release status detail

For every release with decisions being made automatically, you can access the details of what standard violations were found that led to the automatic decision. 

Common Configurations

Deny packages with no review
In this configuration, you've established that packages with violations should never be allowed in your project; the violations are severe enough to not need administrator review to deem them as such.

The violations that exist in your organization can still be seen in reports and the API. Eg. Critical security vulnerabilities.

Deny packages with review
In this configuration, packages with violations should not be used, however an administrator can review to check the automated decision. Example: High or medium severity security issues.

Approve packages with no review
In this configuration, packages with violations can continue to be used because the issues aren’t severe enough to be prioritized. Example: Low severity security vulnerabilities

Approve packages with review
This can be seen as a warning mode. Packages that violate this standard will be approved, but a task will be generated so an administrator can be aware of the issues and potentially deny a particular package.