Maven Repository Group endpoint to support sub-groups
Problem to solve
The GitLab Maven Repository allows users to build, publish and share their Maven packages right alongside their source code and pipelines leveraging the Maven client or GitLab CI/CD. Users can publish their packages to a specific project and download packages at the group and instance level.
However, we do not currently support downloading packages at the sub-group level. This is problematic for larger organizations that utilize sub-groups to organize their teams and repositories. Adding sub-group support would unblock many of these organizations.
- I as developer, when I am pulling dependencies for my project, need to be able to access different maven packages at the sub-group level, so I don't have to create duplicate packages and introduce risk into development process.
- I as a developer, when I am looking for Maven packages that have been created in other projects, need to be able to discover packages at the group and sub-group level, so that I can easily find what I am looking for.
GIVEN a project structure like groupA/group1/myProject1, groupA/group1/myProject2, groupA/group2/myProject3 WHEN accessing https://gitlab.com/api/v4/groups/groupA/-/packages/maven THEN artifacts from the projects 1,2 and 3 should be visible
GIVEN a project structure like groupA/group1/myProject1, groupA/group1/myProject2, groupA/group2/myProject3 WHEN accessing https://gitlab.com/api/v4/groups/groupA/group1/-/packages/maven THEN artifacts only from the projects 1 and 2 should be visible
GIVEN a project structure like groupA/group1/myProject1, groupA/group1/myProject2, groupA/group2/myProject3 WHEN accessing https://gitlab.com/api/v4/groups/groupA/group2/-/packages/maven THEN artifacts only from the projects 3 should be visible
- Provide a consistent user experience by allowing users to download packages (from any format) at the project, group, sub-group and instance level.
- There is a separate issue to create less strict naming conventions for Maven, it's worth reading the issue and commenting there.
- There is also a discussion on why simplifying naming conventions across package manager formats is a good idea and something we should tackle.
- Expand the Maven group level endpoint to support sub-groups, so that teams can download Maven packages at the sub-group level.
Permissions and Security
The permissions will not need to change. Any user with reporter access and above can download packages using the new sub-group endpoint. However, only developers with permission to the project can upload and delete them.
|Pull from Maven repository or NPM registry or Conan Repository||x||x||x||x|
|Publish to Maven repository or NPM registry or Conan Repository||x||x||x|
- Test that there are no violations of the permissions model and only users that have the required permissions can download packages.
What does success look like, and how can we measure that?
- Success looks like we have unblocked our large enterprise customers that are using sub-groups from downloading Maven packages.
- We can measure success by measuring total adoption of the Maven Repository.
- Page views to
- Number of Maven packages downloaded over time
- Page views to
What is the type of buyer?
- Escape the
/in the group/subgroup name, for example, using the URL encoded version