Open robert-king opened 10 months ago
There's some spikes we've done around this that we may move forward with. With this being pretty integrated in core it would likely be an internal developer championing the PR.
Could this "reason affected" also be used to show why a task runs when I think it should be cached? I find that really hard to figure out.
This issue has been automatically marked as stale because it hasn't had any activity for 6 months. Many things may have changed within this time. The issue may have already been fixed or it may not be relevant anymore. If at this point, this is still an issue, please respond with updated information. It will be closed in 21 days if no further activity occurs. Thanks for being a part of the Nx community! 🙏
Description
nx show projects --affected --exclude='tag:no-ci' --reason-affected
note the extra --reason-affected flag
output would look like this:
nx show projects --affected --exclude='tag:no-ci' --reason-affected frontend reason=lib[common,..,+1],file[logo.png] backend reason=lib[common] common reason=file[consts.ts] other-lib reason=file[main.ts,...,+5]
in my CI/CD i noticed some apps were affected but i wasn't sure what was affecting them. This would help me quickly understand at least one reason why they were included.
Suggested Implementation
a concise reason is given of the first change found that contributed towards the rolling hash. --verbose could allow larger reason
Alternate Implementations
happy for suggestions, i only spent a few seconds thinking about this. I'd also need some pointers of how to implement.