Support different top-level groups as defined by provisioning request
In support of a request from Mike, we should support different top-level groups as defined in the Gitlab issue https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/47. Some initial questions around provisioning of these top-level groupings.
- Currently there is a need for
eclipse
andeclipse-wg
as root groups (just example paths rather than names, doesn't need to be that necessarily). In the future, we will likely want to support OpenHWGroup in Gitlab and have a separate category. When looking at these different categories, should we expect them to be hardcoded somewhere, whether an API or in the script, or should we just parse the repos we get to watch for new top-levels? - Follow up on the previous point, if a repo would indicate a group that hasn't yet been provisioned, do we want to create it as part of the sync script? We can easily do that as part of the sync, or note that something doesn't exist yet and just continue processing. Both could be valid stances here.
Edited by Chris Guindon84