Updating your Artifactory instance from Tidelift catalogs

The Tidelift → Artifactory integration ensures that Artifactory reflects the decisions made in your Tidelift catalog.

Artifactory cloud and self-hosted are both supported, but work slightly differently.

With self-hosted, approving or denying a release in your catalog will update a tidelift.status property on the original artifact in a configured Artifactory repository. An Artifactory plugin then controls downloads from the Artifactory repository based on the property. When tidelift.status is set to denied for a given package release, developers will receive a 403 Forbidden error when attempting to download the package for use from Artifactory.

With Artifactory cloud, there's no plugin involved. Instead, approving a release will download it to the Artifactory repository, while denying a release will delete it from the Artifactory repository.

When configuring Artifactory, keep in mind that developers will need the ability to try out new packages that haven't yet been approved, and then ask to approve them. As a result, we recommend separate Artifactory repositories for use on developer desks, vs. for use in the CI/deployment pipeline. The developer desk repository would be permissive while the deployment pipeline only allows approved artifacts.

See also

Using Tidelift with JFrog Artifactory self-hosted

Using Tidelift with JFrog Artifactory cloud

Setting up your catalog with JFrog Artifactory