Trouble building LDAP plugin

Contributing Code
1

Hello!

This might not be the best place for this question but seemed like where the experience base would be. :slight_smile:

I’m helping the team that runs our Jenkins instance move to LDAP authentication and we ran into a situation where it would fail some users due to the LDAP management stack being used uses pwdLockout to mean something different than the plugin assumes. It was decided that the more practical solution was to manage a copy of the plugin that handles that check differently. Easy enough, just changing a string constant.

However, using the instructions, it seems to fail to build? I expect this is because there is some expectation I don’t have that it has for running the tests:

[ERROR] hudson.security.LdapMultiEmbeddedTest.loginWithBrokenServerInTheMiddle  Time elapsed: 99.408 s  <<< FAILURE!
java.lang.AssertionError: hnelson should not be able to login because there is a broken server in between
	at org.junit.Assert.fail(Assert.java:89)
	at hudson.security.LdapMultiEmbeddedTest.loginWithBrokenServerInTheMiddle(LdapMultiEmbeddedTest.java:147)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
	at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:608)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.lang.Thread.run(Thread.java:833)

Any pointers?

Apache Maven 3.8.5 (Red Hat 3.8.5-3)
Maven home: /usr/share/maven
Java version: 17.0.7, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-17-openjdk-17.0.7.0.7-5.fc37.x86_64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.3.8-100.fc37.x86_64", arch: "amd64", family: "unix"
2

Which instructions did you follow? Starting with a fresh clone of the repository using

  • maven 3.9.3 (the same version which we use to build plugins on ci.jenkins.io at the moment)
  • openjdk version “20.0.1” 2023-04-18
  • MacOS 13.4.1 (c)

building with the arguments mvn clean verify package, I get a successful result.

3

That’s fair. I used the instructions in the plugin readme.

How to install
--------------

Run

	mvn clean package

to create the plugin `.hpi` file.

mvn clean verify gave me the same failure.

I will see about updating versions to match your build environment and see if maybe it’s handling an error differently in these slightly staler versions that Fedora provides.

Thank you for the response.

4

Well…

$ ../apache-maven-3.9.3/bin/mvn -v
Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
Maven home: /home/dbolack/Checkouts/apache-maven-3.9.3
Java version: 20.0.1, vendor: Oracle Corporation, runtime: /home/dbolack/Checkouts/jdk-20.0.1
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.3.8-100.fc37.x86_64", arch: "amd64", family: "unix"

No change. Makes me wonder if I need more of something in my environment.

I stepped back off of HEAD and used the target listed on the last release and no change there.

5

The test failure is likely specific to your local environment, though I suspect that the plugin maintainers will be interested to hear what you learn when you determine what it is about your environment that causes the test to fail.

Tests pass on my Red Hat Enterprise Linux 8 machine with Maven 3.8.5 (downloaded from Apache) and Eclipse Temurin Java 11.0.19. Tests pass on ci.jenkins.io with Maven 3.9.3 and Eclipse Temurin Java 11.0.19.

The failing test may indicate that something in your configuration is causing a login in the automated test to succeed when the test expected it to fail. The test intentionally inserts an unresponsive server into the LDAP configuration and then asserts that the login should fail. In your environment, the login succeeds unexpectedly.