If you are using a Tidelift catalog, you can check alignment (i.e. if a project is using only approved package releases) quickly using the Tidelift CLI. Using tidelift alignment does not update the software bill of materials (SBOM) for the project and only requires a user API key. To update the SBOM for the project and create a record of the alignment, use tidelift alignment save; this is ideal for CI/CD as it will require a project API key.
Checking local build alignment
- To check for your catalog alignment, you will first need to have a user API key to authenticate to the API. Be sure to note your team name when downloading your API key.
- From your project's root directory run
tidelift alignment --project PROJECT_NAME --organization ORGANIZATION_NAME. PROJECT_NAME is the name of the project as set up in Tidelift. - From your project's root directory, run
tidelift alignment. - Once the alignment check completes, you will see the percent of package releases in the current project that are approved in the organization's catalog.
- If any package releases are not available, you will see if you should request them using
tidelift request --alland/or why they were previously denied.
Checking alignment as part of Continuous Integration
To check for your catalog alignment as part of your continuous integration process, you will need to create a project API key. Once a project API key is stored in your CI/CD system, you can run
tidelift alignment save. This will update the bill of materials for the project and create a record of the alignment.Output from an alignment check
There are a few ways you can configure what type of output you receive from an alignment check.
By default, the response will either succeed or fail based on whether or not the alignment score is 100% (ie. every package in the project is also approved in the catalog).
If you want more control over when, we also provide raw counts such as the number of approved, denied, and unrequested releases in a project. See the "Checking alignment in more nuanced ways" section of this article for documentation on how to access this information from the JSON output.
This JSON output contains other information valuable to developers, such as alternative, already-approved releases and if those alternatives are already in use. For example, in the screenshot below `addressable 2.8.0` is being used by a project and is denied in the catalog. 2.5.2, 2.6.0, and 2.7.0 are all approved alternatives, although none of them are currently in use by any other project.
