search

quarkusio / registry.quarkus.io

Quarkus Extension Registry application
https://registry.quarkus.io
Apache License 2.0
10 stars 11 forks source link

Registry client profiles #135

Open aloubyansky opened 2 years ago

aloubyansky commented 2 years ago

This idea was inspired by a discussion around which platform release streams should be listed for users on code.quarkus to select from for new project creation vs which streams should be used by the CLI tools (by default) to calculate the best suited platform release for a given set of extensions. For example, code.quarkus could use more streams, including CRs, Alphas, etc. While the CLI, by default, could recommend only the final versions (given that in the CLI tools, a lot of options are implicit and there is no way to visualize them unlike in code.quarkus).

Currently, the registry client used by all the tools provides the same list of "recommended" platform streams for new project creation to every client. It's mostly adapted for code.quarkus and includes CRs and some older versions. This does affect the UX for the CLI users because the CLI based tools refresh the local cache daily on the first command execution, i.e. it takes time for the first CLI command to complete due to the catalog refresh. The more streams the registry promotes in that list, the longer it takes to refresh the local catalog cache.

The idea behind this request is to allow creating different registry client "profiles" that would be managed in the registry itself. Today clients have three options when they request a platform catalog:

  1. Get the current default list of platform releases (the recommended one)
  2. Get a list of platform releases for a given quarkus (core) version
  3. Get a list of all the registered platform releases by passing all in place of the quarkus version (https://github.com/quarkusio/registry.quarkus.io/commit/c54dd92827fdfa0829b9589e2e264e4187351a56)

The idea here is to allow clients to pass their profile id, e.g. code.quarkus, instead of a quarkus version or all, that the registry would recognize and return a list of platform releases adjusted for that particular profile. That way we could isolate the lists of platform releases displayed on code.quarkus from those used by the CLI tools by default. In case of the Maven client, a profile id would be passed in as a classifier, similar to the quarkus version and all use-cases.

Note, we still want to keep the 1 option above. Perhaps, we could keep 1 for the CLI-based tooling, i.e. recommending only a limited selection of Final releases. While code.quarkus profile would enable a few more, including CRs.

maxandersen commented 2 years ago

Would this still reuse the "recommended" list - meaning if we some day in code.quarkus or other would want to find which stream is relevant for certain set of extensions then code.quarkus wouldn't be able to do that using same list as the cli without doing additional queries ?

or would it be a separate list so all tools will offer the same uniform result no matter which profile they use for their listing?

aloubyansky commented 2 years ago

The algorithm that selects the preferred platform release(s) and Quarkiverse extensions accepts a list of platform catalogs to choose from. It will select the preferred combination based on what you provide as input. We can provide it with all the registered platform releases or the last two. If code.quarkus use that algorithm to recommend the Quarkus platform release, it would select the preferred release from the list of platform releases provided by registry for the "code.quarkus" profile. While the CLI would select the preferred release from the list of platform releases provided by registry for the "cli" profile.