Improve discovery and navigation for GitLab Package features
Problem to Solve
GitLab Package features are in three different sections of the top-level navigation. This hurts the discoverability, usability and scalability of the Package stage. As we launch more features and integrations for the Package stage, we need to ensure that they have a consistent, easy-to-find navigation path.
This means grouping features under a top-level navigation item to immediately improve discoverability and ensure we have a place to nest future product features, such as metrics and policies related to the Package stage.
This problem became more evident with the launching of the Dependency Proxy, which is currently nested under Project.
Proposal
Add a new top-level navigation item called "Packages" at both the Group and Project level and nest our current and any future GitLab Package features under "Packages"
Group -> Packages:
- List: aggregates all packages from all projects within the group (Maven, npm and future integrations).
- Dependency Proxy:
NOTE: This is addressed in MR https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14089
Project -> Packages:
- List: aggregates all packages for a given project (Maven, npm and future integrations).
- Container Registry: project level view of the container registry
Further Details
Group vs. Project Level
The Dependency Proxy is intended to operate at the group level because:
- We have too much complexity in project itself. If we can unload some features that are necessary only on a group level, we should do it.
- Putting the feature into the same UI as a container registry is confusing for a user. You should be able to use a registry proxy even if you don't use a registry itself.
- People are likely to create one project per group and re-use it for a whole group as a single proxy endpoint.
- In future we introduce dependency proxy for maven and npm. It makes sense to have all dependency proxy features in one place in UI.
- Billing is on a group level so it can be used on GitLab.com
We currently do not offer any visibility into the Container Registry at the Group Level. https://gitlab.com/gitlab-org/gitlab-ce/issues/49336 will aim to address this and help users to better manage their registries at the group level.
Permissions and Security
There are a few permissions and security items to consider:
- The Container Registry is on by default for projects. However, any projects before GitLab 8.8 will have to manually enable it.
- The Maven and NPM registries, which will be under the Registry navigation item are enabled by default for Premium and Ultimate instances. The same will be true for our upcoming integrations such as Conan, NuGet and RubyGems.
- The Dependency Proxy is on by default at the instance level for Premium and Ultimate customers. https://gitlab.com/gitlab-org/gitlab-ee/issues/11638# will enable it by default at the Group level for Premium and Ultimate customers.
Documentation
- The Container Registry documentation will have to be updated to reflect the new navigation menu.
- There may be additional marketing content or training videos that will need to be updated.
Testing
We must test that nothing was broken and that we do not introduce any broken links into the UI. In addition, we will verify that the API for any of the features is impacted.
What does success look like, and how can we measure that?
Success looks like we have all relevant features for Package nested under a logical menu item.
What is the type of buyer?
Although the Container Registry is available for all account types, many of the advanced Package features are focused on our Premium and Ultimate customers.