Developers can review their own projects to identify worthwhile work
The same information from the all-projects reports can be found in the Tidelift UI on each individual project (and if you’ve configured it, on each feature branch or pull request where you run Tidelift's alignment analysis).
Looking at an individual alignment,
- The “Denied Releases” tab shows you how to move the approved releases metric, which corresponds to the all-projects compliance report. Typically, avoiding denied releases also improves your violations-by-standard metrics.
- The “Actions to Take” tab shows you how to remediate violations by making the smallest upgrade that will solve the problem; this will also move your approved releases and violations-by-standard metrics. This tab corresponds to the all-projects violations report.
- The “Bill of materials” tab includes a column for the Tidelift recommendation, which corresponds to the all-projects package quality report. Not-recommended packages pose a higher risk and should be removed if possible.
Taking action
Avoiding violations can be challenging. Dependency chains are complicated and manually sifting through release requirements to identify updates that are both compatible and violation-free is incredibly time consuming. Luckily, Tidelift makes this easier with developer violation actions.
These actions relieve developers from the burden of analyzing dependency chains and provide simple guidance on how to avoid a particular violation. Actions can be found on a project’s alignment page.
How developer actions work
For each violation found in your alignment, Tidelift analyzes the dependency chain and the release requirements for each package in the chain. It then looks at all potential variations of the dependency chain to find the smallest action you can take to avoid a violation.
Example
Imagine your project relies on astral_adapter:1.0.0 which has the following dependency chain and release requirements.
Dependency chain
astral_adapter:1.0.0 (direct dependency)
└ bionic_builder:1.0.0
└ cosmic_cybercore:1.0.0 (⚠️ violation)
└ dimensional_downloader:1.0.0
Release requirements
astral_adapter:1.0.0 requires bionic_builder >= 1.0.0
bionic_builder:1.0.0 requires cosmic_cybercore = 1.0.0
cosmic_cybercore:1.0.0 requires dimensional_downloader >= 1.0.0
Scenario
As you run an alignment, Tidelift detects a violation with cosmic_cybercore:1.0.0 a transitive dependency of astral_adapter:1.0.0 . The violation is fixed in cosmic_cybercore:2.0.0.
Unfortunately you can’t simply update cosmic_cybercore to 2.0.0 because bionic_builder:1.0.0 only allows cosmic_cybercore:1.0.0 in its requirements.
In this situation, Tidelift would look at all of the potential updates within this dependency chain to determine the smallest change the meets the release requirements and avoids the violation.
Resulting violation action
As Tidelift does its analysis, it finds that bionic_builder:2.0.0 is available and requires cosmic_cybercore:2.0.0. and the release requirements for cosmic_cybercore:2.0.0 haven’t changed from cosmic_cybercore:1.0.0.
This means the violation action to take is to update the transitive dependency bionic_builder from 1.0.0 to 2.0.0 .
Limitations
Developer actions currently have a few limitations:
- Transitive developer actions are not yet available for Java / maven
- Actions will avoid the violation found during alignment, but could introduce a different violation when the next alignment occurs.
- Actions do not attempt to optimize for any semantic versioning rules in order to minimize breaking changes.
Feedback
This is a beta feature and your feedback plays an important role in helping us improve the product. As you try this feature, please use the feedback form found in the actions section to tell us where we can improve.