-
Bug
-
Resolution: Unresolved
-
Major
-
jenkins version 1.606
parameterized-remote-trigger-plugin version 2.1.3
downstream jenkins version 1.565.1
I have a jenkins job on jenkins master A. It writes a _params.txt with a variable WITH_COMMIT that I would like to hand off to the downstream jenkins job
#!/bin/bash -ex
WITH_COMMIT=9d1cb20
echo "WITH_COMMIT=${WITH_COMMIT}" > _params.txt
cat _params.txt
I then tell the job to have trigger a parametrized downstream job using the file I created. The job will then try 5 times and fail to run the job
$ /bin/bash -ex /tmp/hudson844666025294030118.sh + WITH_COMMIT=9d1cb20 + echo WITH_COMMIT=9d1cb20 + cat _params.txt WITH_COMMIT=9d1cb20 Triggering this remote job: apiserver-docker_bake_app Not checking if the remote job apiserver-docker_bake_app is building. This job is build #[22] on the remote server. Triggering remote job now. Connection to remote server failed, waiting for to retry - 2 seconds until next attempt. Retry attempt #1 out of 5 Connection to remote server failed, waiting for to retry - 2 seconds until next attempt. Retry attempt #2 out of 5 Connection to remote server failed, waiting for to retry - 2 seconds until next attempt. Retry attempt #3 out of 5 Connection to remote server failed, waiting for to retry - 2 seconds until next attempt. Retry attempt #4 out of 5 Connection to remote server failed, waiting for to retry - 2 seconds until next attempt. Retry attempt #5 out of 5 ERROR: Remote build failed for the following reason: [ssh-agent] Stopped. ERROR: Max number of connection retries have been exeeded. Finished: FAILURE
Hopping on the downstream jenkins host I see the following in the logs (pulled some of the java stack trace to save space)
Jun 17, 2015 2:39:26 PM org.eclipse.jetty.util.log.JavaUtilLog warn
WARNING: Error while serving http://downstreamjenkins:8080/job/apiserver-docker_bake_app/build
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor663.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
...
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: javax.servlet.ServletException: This page expects a form submission but had only {delay=[0]}
at org.kohsuke.stapler.RequestImpl.getSubmittedForm(RequestImpl.java:870)
at hudson.model.ParametersDefinitionProperty._doBuild(ParametersDefinitionProperty.java:139)
at jenkins.model.ParameterizedJobMixIn.doBuild(ParameterizedJobMixIn.java:170)
at hudson.model.AbstractProject.doBuild(AbstractProject.java:1726)
... 89 more
So from what I can tell there should be something more passed to the job:
This page expects a form submission but had only {delay=[0]}
Also from reading documentation on the github page
https://github.com/jenkinsci/Parameterized-Remote-Trigger-plugin
This is done by calling the /buildWithParameters URL on the remote server. (or the /build URL, if you don't specify any parameters)
which is different than the url from the stack trace:
:8080/job/apiserver-docker_bake_app/build
I also noticed something weird compared to my experience with the trigger parameterized downstream job. When defining the parameter file it puts a leading / infront of whatever you put in. Say I enter _params.txt in the box, hit save, go back to config it will now be /_params.txt
Further testing if uncheck "Load parameters from external file" and just enter WITH_COMMIT=9d1cb20 it will get properly handed off to the downstream job. If we used the full commit hash we could use WITH_COMMIT=$GIT_COMMIT but we are using the short rev $(git rev-parse --short HEAD).
Is the problem between keyboard and chair?
