backstage: 🐛 Bug Report: GitlabOrgDiscoveryEntityProvider only supports one group since 1.18.0

📜 Description

In v1.18.0 the group turned required in the GitlabOrgDiscoveryEntityProvider.

As I use a self hosted gitlab instance I would like to be able to import all / most of the groups from my instance. Unfortunately only one group is supported.

👍 Expected behavior

For self hosted instances It should be possible to import all, or at least multiple groups with subgroups into backstage.

👎 Actual Behavior with Screenshots

When not configuring a group the sync fails.

{"class":"GitlabOrgDiscoveryEntityProvider","level":"error","message":"GitlabOrgDiscoveryEntityProvider:gitlabBisdevdomCH refresh failed GraphQL errors: [{\"message\":\"Internal server error\"}]","plugin":"catalog","service":"backstage","stack":"Error: GraphQL errors: [{\"message\":\"Internal server error\"}]\n at GitLabClient.getGroupMembers (/app/node_modules/@backstage/plugin-catalog-backend-module-gitlab/dist/cjs/GitlabDiscoveryEntityProvider-8ed2153b.cjs.js:197:15)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async GitlabOrgDiscoveryEntityProvider.refresh (/app/node_modules/@backstage/plugin-catalog-backend-module-gitlab/dist/index.cjs.js:307:26)\n at async TaskWorker.fn (/app/node_modules/@backstage/plugin-catalog-backend-module-gitlab/dist/index.cjs.js:240:13)\n at async TaskWorker.runOnce (/app/node_modules/@backstage/backend-tasks/dist/index.cjs.js:349:7)\n at async /app/node_modules/@backstage/backend-tasks/dist/index.cjs.js:297:31","target":"GitlabOrgDiscoveryEntityProvider:gitlabBisdevdomCH","taskId":"GitlabOrgDiscoveryEntityProvider:gitlabBisdevdomCH:refresh","taskInstanceId":"4931fee3-2407-4fd2-9ce8-d88414aff514","type":"plugin"}

If I define a group, only this one and it’s members are imported.

👟 Reproduction steps

configure the GitlabOrgDiscoveryEntityProvider as documented in https://backstage.io/docs/integrations/gitlab/org

📃 Provide the context for the Bug.

  providers:
   
    gitlab:
      my-instance:
        host: gitlab.my.com
        orgEnabled: true
        schedule: # optional; same options as in TaskScheduleDefinition
          # supports cron, ISO duration, "human duration" as used in code
          frequency: { minutes: 30 }
          # supports ISO duration, "human duration" as used in code
          timeout: { minutes: 3 }

🖥️ Your Environment

Backstage 1.18.3

👀 Have you spent some time to check if this bug has been raised before?

I checked and didn’t find similar issue

🏢 Have you read the Code of Conduct?

I have read the Code of Conduct

Are you willing to submit PR?

None

About this issue

Original URL
State: closed
Created 9 months ago
Reactions: 2
Comments: 15 (7 by maintainers)

Most upvoted comments

When checking gitlab logs I found the following error

Types::UserStateEnum::UnresolvedValueError (`User.state` returned `"ldap_blocked"` at `group.groupMembers.nodes.6.user.state`, but this isn't a valid value for `UserState`. Update the field or resolver to return one of `UserState`'s values instead.):

So it seems to be an issue with gitlab which should hopefully be covered by the MR from @jboeijenga

bakito on Oct 11, 2023

I came across this issue as well and I think I found the rootcause.

The graphQL query that is used to fetch the group users also requests the users state:

query getGroupMembers($group: ID!, $relations: [GroupMemberRelation!], $endCursor: String) {
  group(fullPath: $group) {
    groupMembers(first: 100, relations: $relations, after: $endCursor) {
      nodes {
        user {
          id
          username
          commitEmail
          name
          state
          webUrl
          avatarUrl
        }
      }
      pageInfo {
        endCursor
        hasNextPage
      }
    }
  }
}

However this state enum does not contain the banned state. Screenshot 2023-10-05 at 09 49 36

Therefore, when we run this query for a group that contains a banned member you will receive the Internal server error

I solved it by changing the banned state of the banner users to blocked and the query was running fine again.

I create an MR with gitlab to add the missing banned value to the UserStateEnum https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133398

jboeijenga on Oct 5, 2023