artifacthub / hub Goto Github PK

Some charts are deprecated so they should not be listed and searched like the others. To know if a Chart is deprecated there is a property, deprecated: true, in the Chart.yaml file. There are two ways this can be handled.

1. Do not display them at all
2. Don't display them by default but have an opt-in to display them via the faceted search

I am leaning towards number 2 but either would work.

I've heard feedback from others that the CNCF hub homepage should show more information about the project on the site.

This section in the README is great (thanks @mattfarina!):

Discovering artifacts to use with CNCF projects can be difficult. If every CNCF project that needs to share artifacts creates its own Hub this creates a fair amount of repeat work for each project and a fractured experience for those trying to find the artifacts to consume. The CNCF Hub attempts to solve that by providing a single experience for consumers that any CNCF project can leverage.

The project, accessible at https://hub.cncf.io, is currently in development in a pre-alpha state. Support for Helm charts is in development with plans to support more projects to follow. Pull requests, especially those to support other CNCF projects, are welcome.

If there was an "About' page for the CNCF Hub describing its intent, that would be help users landing on the homepage better understand the goals of this project.

For reference:

• Helm Hub has an About page that redirects to https://github.com/helm/hub/blob/master/README.md
• DockerHub describes its intent in the landing page.

Some examples:

• banzaicloud-docs
• chartmuseum

When listing all chart repositories belonging to a given user, we should probably provide some extra information like the number of packages in the repo, as well as the bits detailed in #170.

The URL to the package contains a UUID and isn't clear as to what this is. For example, https://hub.cncf.io/package/6c1a41a7-0143-4138-a760-9154e232cd57.

But, if I look at other package websites this not the case. The package name is part of the URL. This holds true for https://npmjs.org, https://packagist.org, https://formulae.brew.sh, https://chocolatey.org/, https://hub.docker.com/, https://snapcraft.io/, and the others. I tried to mix in both programming language and operating system ones. Do any others that list packages use a UUID?

Can we get a structure to the URLs that has names in it? Given that this has to deal with charts in OCI registries and Helm repositories along with operators in unknown formats and other things this may be complicated. But, I wanted to broach the subject.

Depends on #94, #95

In the metadata about a chart there's a keywords section...

I found myself wanting to click on the keywords to see what else had those same keywords. As a sort of browsing by type.

This is a feature request for that.

We should probably track:

• Last time the repository was indexed
• Errors loading the repository index file

The goal is to expose this information in the repositories management page so that owners can take action and fix any potential issue.

Let us know when you make the CNCF TOC PR for Sandbox Status for this rebranded helm chart-based hub project and make the code available for public comment. We'll review to ensure it supports all the operator packaging patterns including Operator Framework, Kubebuilder/Kudo, Rudr and others that are currently under development. @mattfarina @dankohn

The install section for charts explains how to add a repository and install a chart like so...

Unless the chart is in the stable repository. Then it doesn't...

This is a bug in the Helm Hub we need to correct. Even for the stable repository the information for adding the repository should be listed.

To add some context, Helm 2 automatically added the stable repository. Helm 3 does not. A significant number of people have moved to Helm 3 and need this information now.