|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Code changed in jenkins
User: tim.brown5
Path:
src/main/java/org/jenkinsci/plugins/ParameterizedRemoteTrigger/RemoteBuildConfiguration.java
src/main/resources/org/jenkinsci/plugins/ParameterizedRemoteTrigger/RemoteBuildConfiguration/config.jelly
http://jenkins-ci.org/commit/parameterized-remote-trigger-plugin/d32c69d0033aefda382c55e9394ebab8d1da10ae
Log:
Created new fork and commit mesasges to local branch to it:
commit dab42e57ce1a1b9ca1b2f8251f2d89127cd69d04
Author: tim.brown5 <tim.bro...@hp.com>
Date: Mon Jan 27 17:40:43 2014 +0000
Added the ability to specify a PollInterval value - to stop the plugin spamming the logs. Also Fixed some typos in the field titles in config.jelly.
commit 81558c521857bea4c0d0c6c951b759f8e28bdab4
Author: brownt <tim.bro...@hp.com>
Date: Thu Jan 23 15:10:27 2014 +0000
Changed the tile of check box from 'Block execution of remote builds while other builds are running.' to 'Block triggering of remote builds while other builds are running.' to better describe what it does.
commit b78f021cd0b7ddccd3e84fc2fc2758fd8d92a092
Author: brownt <tim.bro...@hp.com>
Date: Thu Jan 23 15:08:25 2014 +0000
Added to checkBoxes to allow toggling of the following fnctionality:
The first gets round an issue where multiple jobs are all trying to launch jobs at once and filling up the build queue on the remote server. This causes an issues because when jobs are in the queue you cannot get their status. Another way to solve this would be to assume that the job is in the build queue and 'qait' until you can access the job's build page.
The second allows the user to make the local job block until the remote job has finished (and so set the status of the local job to that of the remote job). This is a fix for issue JENKINS-20828. If you are using this feature it's best to also use the feature above, as otherwise your builds will fail when remote builds you have triggered are waiting in the build queue.
This works best if only one job is triggering builds on a remote job. This is because is two builds trigger a job at the same time it is possible for them both to think next next build is the one they triggered... A solution to this could be comparing the parameters??
commit 22983d13fc8a1b63b3686facfcd10d31d51f074a
Author: brownt <tim.bro...@hp.com>
Date: Wed Jan 22 15:37:41 2014 +0000
Added 'fix' as describe in: https://issues.jenkins-ci.org/browse/JENKINS-20828
Feel free to ignore this branch if you are working on this yourself. Also free free to use this code as you see fit.
"I have created a workaround/fix for this issue. My code does the following:
get the nextBuildNumber from the job
trigger the build
check that next build number has increased by one - this means we know that the only job triggered is the one we triggers, otherwise we error
then wait for the job with the build number above to start
then wait for the job with the build number above to finish and return the result.
I can share the code if you are interested
*I also split out the HTTPRequest code into a method, so you can call different URLs with different methods (to simplify the communication with the remote server).
I do agree however, it would be a lot easier if the trigger call returned the build number of the job it's just triggered. Could raise an issue to see if this can be done?
"
There are issues with this 'fix' when multiplem jobs are triggering the same remote job:
1. It blocks all the time - would probably need to add a toggle button to turn the blocking on/off
2. It returns failure if it tries to check on a remote job and the job has not started yet - as it goes to the job
3. If two jobs are launched at the same time they can both pickup the same job ID - so they
To test this I setup multiple local jobs all triggering one remote job. When running them all one at a time there were no issues, but running them all at once there were issues.