What changed in Repository Health Check 2.0?

Nexus UX - Featured Image

Nexus UX - Take the Survey

Since releasing Repository Health Check (RHC) 2.0 a few weeks ago, a number of you have asked what changed, and why. Great questions. Let’s start with the why.

Why change RHC at all?

Put simply, we wanted to give repo admins a straightforward way to improve the health of their repositories over time. RHC is an obvious place to do this, but the previous version had three issues that kept it from being used this way:

  • The information was not actionable. It told repo admins about vulnerabilities in the aggregate, but didn’t provide the detail needed to help them remediate those vulnerabilities.
  • Active risk was not the focal point. It treated all components in a repo the same, regardless of usage
  • Like a continuous false alarm with a smoke detector, it made noise about many issues that are likely not relevant (e.g. components not in use; “bad” licenses which might not be an issue given usage; low priority vulnerabilities that are unlikely to pose a significant risk)

In short, the above issues led to an experience with RHC that was not providing real value for users.

(That said, if there is something about the old RHC that you miss, we’d love to talk with you. Please fill out this survey and we’ll be in touch soon.)

What changed in RHC 2.0?

RHC 2.0 improves on the old RHC in three important ways:

  • It surfaces specific components in need of remediation.
  • It filters the list of vulnerable components by impact (e.g. bad components with downloads in the last 30 days).
  • It removes all licensing info, since this is only relevant in a Lifecycle application context anyway.

In short, RHC 2.0 provides actionable information that is intended to provide meaningful engagement for people.

Where do I submit feature requests?

We plan to continue improving RHC based on your feedback. If there’s anything you miss from the old RHC or new features you’d like to see added, we’d love to hear from you!

Please fill out this survey, and we’ll be in touch.

The following two tabs change content below.

Daniel Sauble

Daniel Sauble is a product owner and UX designer at Sonatype. His team is focused on providing a great experience for travelers as they bounce between the different products in the Nexus ecosystem. He reads nexus-feedback@sonatype.com at breakfast each morning.
Tags , ,

Related posts