2024-09-10 10:32:52 +02:00
parent 87104c7e7b c81b8c10ce
commit 543b35d745
7 changed files with 101 additions and 9 deletions
@@ -171,7 +171,10 @@ catalog:
        host: gitlab.com
        orgEnabled: true
        group: org/teams # Required for gitlab.com when `orgEnabled: true`. Optional for self managed. Must not end with slash. Accepts only groups under the provided path (which will be stripped)
        allowInherited: true # Allow groups to be ingested even if there are no direct members.
        relations: # Optional
          - INHERITED # Optional. Members of any ancestor groups will also be considered members of the current group.
          - DESCENDANTS # Optional. Members of any descendant groups will also be considered members of the current group.
          - SHARED_FROM_GROUPS # Optional. Members of any invited groups will also be considered members of the current group.
        groupPattern: '[\s\S]*' # Optional. Filters found groups based on provided pattern. Defaults to `[\s\S]*`, which means to not filter anything
        schedule: # Same options as in SchedulerServiceTaskScheduleDefinition. Optional for the Legacy Backend System.
          # supports cron, ISO duration, "human duration" as used in code
@@ -193,6 +196,32 @@ entities will only be ingested for the configured group, or its descendant group
but not any ancestor groups higher than the configured group path. Only groups
which contain members will be ingested.
### Subgroup Membership
GitLab groups and subgroups provide a hierarchical structure for organizing projects and users. Membership in a parent group extends automatically to its subgroups, ensuring consistent permissions at all levels. Additionally, membership can be managed using invited groups, where one group can be added to another. For Backstage users integrating with GitLab, understanding this [inheritance model](https://docs.gitlab.co.jp/ee/user/group/subgroups/#subgroup-membership) and the concept of invited groups is crucial for accurately mapping and managing group and user entities.
The `GitLabOrgDiscoveryEntityProvider` mirrors GitLab's membership behavior as follows:
- By default, every direct member of a GitLab group is also a member of the corresponding group in Backstage.
- To include members of subgroups as members of the parent group, configure the `relations` array with the `DESCENDANTS` option.
- To include members of parent groups as members of their subgroups, configure the `relations` array with the `INHERITED` option. This also has the effect that subgroups with no direct members will not be skipped in the group ingestion process and will be added as a group entity in Backstage;
- To include members of invited groups as members of the inviting group, configure the `relations` array with the `SHARED_FROM_GROUPS` option.
The previous `allowInherited` will be deprecated in future versions. Use the `relations` array with the `INHERITED` option instead.
```yaml
catalog:
  providers:
    gitlab:
      development:
        relations:
          - INHERITED
          - DESCENDANTS
          - SHARED_FROM_GROUPS
```
Refer to the [GitLab Group Member Relation](https://docs.gitlab.com/ee/api/graphql/reference/#groupmemberrelation) documentation for more information.
### Users
For self hosted, all `User` entities are ingested from the entire instance by default.