"Lando Required" hook does not check LDAP to map DN to email
Categories
(Developer Services :: Mercurial: hg.mozilla.org, defect)
Tracking
(Not tracked)
People
(Reporter: sheehan, Assigned: sheehan)
References
(Regression)
Details
Attachments
(1 file)
After turning the "Lando required" hook on for autoland, inbound and central, Jan reported being unable to land a patch via Lando in https://lando.services.mozilla.com/D39304/. The error is there but I'll copy it here for reference:
On Thu, July 25, 2019, 9:45 AM EDT, by jdemooij@mozilla.com.
Revisions: D39304 diff 137059
Details: hg error in cmd: hg push -r tip upstream:
pushing to ssh://hg.mozilla.org/integration/autoland
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote:
remote: ******************************************* ERROR ********************************************
remote: Unable to retrieve LDAP information about you, therefore we cannot allow remote: your push to proceed. This is a fatal error.
remote: You may retry your push in the hopes that this a transient problem.
remote: If this problem persists, please report this error by filing a bug at <https://mzl.la/2HX9Te2>
remote: **********************************************************************************************
remote:
remote: transaction abort!
remote: rollback completed
remote: pretxnchangegroup.mozhooks hook failed
abort: push failed on remote
So the error here is "unable to retrieve LDAP information about you", which is displayed when either the USER environment variable is absent or no LDAP groups were retrieved for the user.
|
Assignee | |
Comment 1•5 years ago
|
||
After some discussion on Slack with :jabba, we determined that the issue here comes from creating the DN manually using a format string, rather than checking with LDAP. Changing get_active_scm_groups to check with LDAP instead should fix the problem.
|
|
Assignee | |
Comment 2•5 years ago
|
||
Previously we created the DN using a format string, however this
will only be correct when looking up real Mozilla employee entries.
Looking up other entities (namely, bots) causes no groups to be
returned. This commit adds an extra LDAP lookup to map the email
to the correct DN, which should cause the correct behaviour in
both cases.
Pushed by cosheehan@mozilla.com:
https://hg.mozilla.org/hgcustom/version-control-tools/rev/24c9618eed4a
ldap: perform lookup to map email to LDAP DN r=smacleod
Description
•