VALORFLOW-16: Add ldap group retrieval to groups#27
Conversation
Trying to set up default owners files via LDAP groups for github, it appears that the ldap groups are in the index, but aren't retrieved by group lookups? It doesn't seem like it should hurt anything to retrieve that too -- I'm assuming it was more that nobody had a need to use it yet vs an intentional exclusion. This just adds people_ldap_groups to the list of fields returned by the group struct so I can get at them. Signed-off-by: John Kyros <jkyros@redhat.com>
openshift-ci-robot
added
the
jira/valid-reference
|
@jkyros: This pull request references VALORFLOW-16 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: jkyros The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
WalkthroughThe PR adds support for LDAP group mapping in team/group data by introducing a new ChangesLDAP Groups Field Addition
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.12.2)level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies" Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
go/team_test.go (1)
657-682: ⚡ Quick winConsider testing the empty LDAP groups case.
The test data includes entities without
people_ldap_groups(e.g., orgs liketest-org), which is good for backward compatibility. Consider adding a test case to verify that entities without this field return an empty slice, confirming theomitemptybehavior works as expected.🧪 Proposed enhancement
if platform.Group.PeopleLDAPGroups[0] != "platform-team-ldap" { t.Errorf("expected LDAP group 'platform-team-ldap', got '%s'", platform.Group.PeopleLDAPGroups[0]) } + + // Verify backward compatibility: orgs without people_ldap_groups should return empty slice + org := service.GetOrgByName("test-org") + if org != nil && len(org.Group.PeopleLDAPGroups) != 0 { + t.Errorf("expected empty LDAP groups for test-org, got %d", len(org.Group.PeopleLDAPGroups)) + } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@go/team_test.go` around lines 657 - 682, Update the TestTeamPeopleLDAPGroups test to also assert that entities without people_ldap_groups return an empty slice: after creating service via setupTestService(t), call service.GetTeamByName("test-org") (or another entity known to lack people_ldap_groups), verify the returned value is non-nil, and add assertions that team.Group.PeopleLDAPGroups is not nil and has length 0; modify TestTeamPeopleLDAPGroups to include these checks using the existing service.GetTeamByName and team.Group.PeopleLDAPGroups references.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@go/team_test.go`:
- Around line 657-682: Update the TestTeamPeopleLDAPGroups test to also assert
that entities without people_ldap_groups return an empty slice: after creating
service via setupTestService(t), call service.GetTeamByName("test-org") (or
another entity known to lack people_ldap_groups), verify the returned value is
non-nil, and add assertions that team.Group.PeopleLDAPGroups is not nil and has
length 0; modify TestTeamPeopleLDAPGroups to include these checks using the
existing service.GetTeamByName and team.Group.PeopleLDAPGroups references.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: a0bf1dad-f704-46a5-ab57-92e22b8d4f8a
📒 Files selected for processing (4)
go/team_test.gogo/types.gopython/orgdatacore/_types.pytestdata/test_org_data.json
2 participants
Trying to set up default owners files via LDAP groups for github, it appears that the ldap groups are in the index, but aren't retrieved by group lookups?
It doesn't seem like it should hurt anything to retrieve that too -- I'm assuming it was more that nobody had a need to use it yet vs an intentional exclusion. If there was a good reason this was omitted from the fields retrieved, let me know 😄
This just adds people_ldap_groups to the list of fields returned by the group struct so I can get at them.