|
||||||||
|
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/d/optout.
Hi Rinrin.
The lockfile has nothing to do with Jenkins. It is merely a file, that the Jenkins Bash Build Step is waiting for, precisely NOT to need to use a fixed sleep time.
This is used to let specific builds of "Test_1" and "Test_2" finish in the desired order, by deleting the "lock files" in the appropriate order. The Bash build step looks like that:
#!bash # Write out a lock file, that delays, until it is deleted lck="LOCKFILE-${JOB_NAME}-${BUILD_NUMBER}" echo "Creating file and waiting for deletion of it: $lck" touch "$lck"while [[ -e "$lck" ]]; do sleep 1 done exit 1It is easy to see, that this buildstep looks like a totally normal build, to both Jenkins and the Gerrit Trigger plugin. It's just a shell build step that is taking some user-defined amount of time.
Thus, the only change over a normal "sleep <time>" is that you, as the debugger, can select the exact order in which these build steps will return.
You can easily change this to a fixed timeout, but that way, you need to be either quick about re-triggering the builds, or make the timeout so long, that you're needlessly waiting for the tests to end.
In any case, the bug is fully and wholly independent of what the build step does. It only matters in which order they return and that the retriggering happens WHILE the previously triggered tests are still running.