New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix user ingestion for GitlabOrgDiscoveryEntityProvider for GitLab.com #18889
Fix user ingestion for GitlabOrgDiscoveryEntityProvider for GitLab.com #18889
Conversation
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: Stephen Barry <sbarry@poppulo.com>
… to SaaS full mutation test Signed-off-by: Stephen Barry <sbarry@poppulo.com>
Signed-off-by: Stephen Barry <sbarry@poppulo.com>
…sers-groups-ingestion
Signed-off-by: Stephen Barry <sbarry@poppulo.com>
Signed-off-by: Stephen Barry <sbarry@poppulo.com>
Changed Packages
|
Uffizzi Preview |
Tested on GitLab Self-Managed (16.1.1) without
|
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
Co-authored-by: Jamie Klassen <jklassen@vmware.com> Signed-off-by: sbarrypoppulo <101636916+sbarrypoppulo@users.noreply.github.com>
…endantGroupsResponse Signed-off-by: Stephen Barry <sbarry@poppulo.com>
…sers-groups-ingestion
Thanks once again for the review @jamieklassen and the very helpful suggesstions 💪 I think we're very close here now, if you can take another look and hopefully over to @alde / @freben We're hoping we can get this in for 1.18 release, as it's preventing us from enabling sign-in resolvers for user identity, which is blocking various options and plugins on out adoption journey 🤞 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome
Very nice work! Also hoping for a 1.18.x release! |
Great work! Anxiously waiting for the merge to use it! |
@freben Any chance of a review here? Seems a few folks are awaiting this fix 😄 |
order to limit the ingestion to a group within your organisation. `Group` | ||
entities will only be ingested for the configured group, or it's descendant groups, | ||
but not any ancestor groups higher than the configured group path. Only groups | ||
which contain members will be ingested. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this a conscious choice or "for technical reasons"? Seems like an unnecessary limitation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for the level within the hierarchy, it made sense that if you configure a group path, then the only groups ingested would be at that group level, or lower. Rather than in the other direction, higher up the hierarchy. Regarding ingestion of only groups with members, this was my understanding of how this always worked, but let me double check on that assumption.
docs/integrations/gitlab/org.md
Outdated
|
||
For gitlab.com, when `orgEnabled: true`, the `group` parameter is required in | ||
order to limit the ingestion to a group within your organisation. `Group` | ||
entities will only be ingested for the configured group, or it's descendant groups, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
entities will only be ingested for the configured group, or it's descendant groups, | |
entities will only be ingested for the configured group, or its descendant groups, |
@@ -136,16 +236,26 @@ export class GitLabClient { | |||
continue; | |||
} | |||
|
|||
memberIds.push( | |||
...response.data.group.groupMembers.nodes | |||
.filter(n => n.user) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to call out the deletion of this one. I vaguely remember it being added for very good reason - it could be the case that the user was null sometimes in the response, for some corner cases. You may want to retain that check, right
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me take another look here. This rings a bell, think I brought up this issue in #17735 and it slipped my mind
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost. I think it needs to be group?.id
and user.user?.id
or so to not throw an error
Apply suggestion Co-authored-by: Fredrik Adelöw <freben@gmail.com> Signed-off-by: sbarrypoppulo <101636916+sbarrypoppulo@users.noreply.github.com>
Signed-off-by: angom1 <angom@poppulo.com>
Should we hold off waiting for the |
Signed-off-by: angom1 <angom@poppulo.com>
We've switched to Further details in the comment here - #18889 (comment) |
Signed-off-by: angom1 <angom@poppulo.com>
Signed-off-by: angom1 <angom@poppulo.com>
See above about |
Signed-off-by: angom1 <angom@poppulo.com>
Thank you for contributing to Backstage! The changes in this pull request will be part of the |
Greate work guys!!! |
Hey, I just made a Pull Request!
Fixes an issue with user ingestion for GitLab.com by making the entity provider aware of the
group
config parameter and scoping the provider to this group. Previously, the Gitlab Org data entity provider attempted to fetch all users from Gitlab.com via the/users
REST endpoint, which was undesirable.Switched the user fetching for Gitlab.com to GraphQL API, scoped to the root Gitlab group for the Org, or via existing
/users
REST API for Gitlab Self-Managed.Groups are fetched via GraphQL API for Gitlab.com and via existing
/groups
REST API for Gitlab Self-Managed.Group members are fetched via existing GraphQL API for both instance types
Example provider configuration used to test with:
Relates to:
✔️ Checklist
Signed-off-by
line in the message. (more info)