Code changed in jenkins
User: Joe Hansche
Path:
gerrithudsontrigger/src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/gerritnotifier/ParameterExpander.java
gerrithudsontrigger/src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/gerritnotifier/ToGerritRunListener.java
gerrithudsontrigger/src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/gerritnotifier/model/BuildMemory.java
http://jenkins-ci.org/commit/gerrit-trigger-plugin/f79e10be25028ad69a433a82b061ebc1bd6371d2
Log:
JENKINS-12881: Obtain failure message at completed-time.
Resolves a potential race condition when a single job
may be executing multiple times before the change "batch"
status is ready to be reported back to Gerrit.
The test setup is:
- Shell: echo "Starting ${BUILD_TAG}" > error-message.txt
sleep 5
- Shell: echo "Always fails ${BUILD_TAG}" > error-message.txt
sleep 5
exit 1
- Shell: echo "Starting ${BUILD_TAG}" > error-message.txt
sleep 15
- Shell: echo "Never fails ${BUILD_TAG}" > error-message.txt
sleep 15
Job-B will always be the long-pole (30 sec). Job-A will always fail,
hopefully with "Always fails ______" as the error-message.
Create 2 commits for review, and push both commits to Gerrit. Both
Job-A builds will run and fail within 20 seconds, before the first
Job-B build is even finished executing.
The test is successful if both review commits contain the correct
"Always fails
{TAG}
" messages, corresponding to the correct URL.
The test fails if any other string exists in the failure message.
The approach I took on this was to have a configurable error file that can be specified in the "Gerrit Trigger" section of config, in the Advanced section. When building the approval message, if the result is not SUCCESS, it attempts to read from the unsuccessful-message file. If that is configured and the file is present, its contents will be appended to that build stats section.
One concern, which my current implementation is susceptible to, is that currently the file is only read once all builds have completed, but that could result in some data integrity issues. Instead, that file's contents should be read as soon as the build is completed, and store the contents to the MemoryImprint instead.EDIT: this has been fixed in the pull request.