Global CI/CD Catalog page
This is move of the comment in #393623 (comment 1591128582).
I'm late to the party. I read the issue Add Namespace catalog to the left navigation (#393623 - closed) and those are my thoughts:
Goals
- It seems that we put too much emphasis on Namespace catalog instead of CI/CD Catalog in general.
- I'm not convinced that the scoping to the namespace is the important objective, since the objective is to make it possible for users to discover all components that they can use in their pipelines regardless where they are coming from.
- I personally do not find that much value in the Namespace-specific catalog. I think we just need to have a single CI/CD Catalog that can present all my components that I can use, be it public or private.
- I think it is NOT important in what namespace I'm in. It is important what I can use / have access to.
Expectations
- My very first expectation would be to find
CI/CD Catalog
inExplore
. - The Pipeline Editor should link to
CI/CD Catalog
containing all resources:- We want user to be able to discover all components in the system: regardless if they are private or public, if they are scoped to organization/namespace or not.
- This is contrary to for ex.
Package Registries
. CI/CD Catalog is meant to allow to re-use things that are published in the system. Where-asPackage Registries
is meant to show packages published in the group. - People are unlikely to look in a specific namespace - as they would first need to know which namespace to look into.
Paid feature
- Group being Ultimate can publish private components to the catalog that will be visible in
CI/CD Catalog
with the indicator that the published component is private as long the user has access to. - Catalog as a feature is accessible to everyone and free. The ability to publish private components to the catalog is a paid feature.
- Public on-premise GitLab's can use their own catalog (free) as long as things are public as well.
- The single CI/CD Catalog page for the tab
GitLab Offical
(orCertified
) could present data pulled from GitLab.com, giving people a way to access on their on-premise GitLab in a single interface what is published on GitLab.com. - Making the CI/CD Catalog to connect to GitLab.com, could also allow us to better support those components for air-gapped installs, maybe like proxying them.
Usability
- I would expect to have tabs in a
CI / CD Catalog
page to be able to quickly filter between:-
All
- all components in a system. -
GitLab Official
(only on GitLab.com) - all components that are provided and managed by us - like all Auto-DevOps/GitLab Pages templates - at some point it will be big category, and it is important for us to have a repository of curated components. Alternative name could beCertified
that could be applied to any component in the system by us. -
Community
- all public community published in a system. -
My Organization
- all components that I have access to as part of being member of all my namespaces, public or private, accessible only for paid organizations. This can alternatively be namedMy Groups
.
-
- We have more recent design that uses a flexible filtering field (as in issues), but we can probably initially replicate what other Explore pages do:
- We need
Filter by name
to make it useful. - We need
Filter by type
- once we introduce steps -
Sort by
seems to be useful as well
- We need
- We could also implement issue-like type of filtering with flexible box. Make Tabs to apply a filters into flexible box. Allow to filter components by group or project, giving the ultimate flexibility. And making possible to use a single page to show components of a given group.
- Out of the list in https://gitlab.com/gitlab-org/gitlab/-/ci/catalog/resources I would very likely drop
fork
count. Stars seems like a good indicator and very likely good default sorting order for Community filter to direct user to most popular one.
Example
I modified in Chrome > Inspect the Explore / Projects
page to better show what I have on my mind. Ignore exact names, it is more to showcase this visually:
This is how we could extend CI/CD Catalog to have a flexible filtering, to allow filter by any criteria (including group or project, if required):
Summary
I think we only need Explore / CI/CD Catalog
to solve all our use-case, be it community, official, or organization specific components.
Edited by Kamil Trzciński