Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
Jenkins 2.121.2, gitlab-oauth 1.4, swarm 3.13, Linux
Description
As soon as gitlab-oauth plugin is enabled new agents cannot be added (which hurts us badly especially if autoscaling kicks in). Immediately after switching the authentication mechanism to something else agents connect successfully.
Here is the log snip from swarm:
INFO: Client.main invoked with: [-mode normal -executors 4 -username slaveswarm -password bleble -master http://x.x.x.x:8080 -fsroot /home/jenkins-slave]
Aug 03, 2018 2:13:40 PM hudson.plugins.swarm.Client run
INFO: Discovering Jenkins master
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Aug 03, 2018 2:13:40 PM hudson.plugins.swarm.SwarmClient discoverFromMasterUrl
SEVERE: Failed to fetch slave info from Jenkins, HTTP response code: 500
Aug 03, 2018 2:13:40 PM hudson.plugins.swarm.Client run
SEVERE: RetryException occurred
hudson.plugins.swarm.RetryException: Failed to fetch slave info from Jenkins, HTTP response code: 500
at hudson.plugins.swarm.SwarmClient.discoverFromMasterUrl(SwarmClient.java:233)
at hudson.plugins.swarm.Client.run(Client.java:146)
at hudson.plugins.swarm.Client.main(Client.java:119)
Aug 03, 2018 2:13:40 PM hudson.plugins.swarm.Client run
INFO: Retrying in 10 seconds
As a heads up, I just ran into this exact problem. The answer was to go and create a Personal Access Token for the user that Swarm is trying to authenticate as and use that in place of the -password <password> option.
I also created a matrix based auth strategy, and assigned the swarm-client user's group to the appropriate permissions to create a CI node.
Hope that helps!