Last modified: 2012-10-19 15:53:08 UTC
When a build it retriggered such as https://integration.mediawiki.org/ci/job/MediaWiki-GIT-Fetching/383/ , Jenkins does not show the build number of children jobs: MediaWiki-Tests-Parser(none) MediaWiki-Tests-Dumps(none) MediaWiki-Tests-Databaseless(none) MediaWiki-Tests-Misc(none) MediaWiki-Tests-API(none) That is confusing user. The workaround is to look at the console which shows the links to the children builds: 20:28:55 Waiting for the completion of MediaWiki-Tests-Databaseless 20:29:00 MediaWiki-Tests-Databaseless #369 completed. Result was SUCCESS 20:29:00 Waiting for the completion of MediaWiki-Tests-Misc 20:29:05 MediaWiki-Tests-Misc #144 completed. Result was FAILURE 20:29:05 Waiting for the completion of MediaWiki-Tests-API 20:29:07 MediaWiki-Tests-API #149 completed. Result was SUCCESS 20:29:07 Waiting for the completion of MediaWiki-Tests-Parser 20:30:00 MediaWiki-Tests-Parser #363 completed. Result was SUCCESS 20:30:00 Waiting for the completion of MediaWiki-Tests-Dumps 20:30:01 MediaWiki-Tests-Dumps #87 completed. Result was SUCCESS The root cause is the way I have setup the fingerprint to work. By using .git/FETCH_HEAD, retriggered builds looks exactly like the original one to Jenkins. It probably loose track and bail out because several builds could be the children's. Example of fingerprints confusion: https://integration.mediawiki.org/ci/fingerprint/b50b24ccbb2025d678854e33c0e120f3/ This file has been used in the following places: MediaWiki-GIT-Fetching Failed#381-Failed#383 MediaWiki-Tests-API Failed#147-Success#149 MediaWiki-Tests-Databaseless Success#367-Success#369 MediaWiki-Tests-Dumps Success#85-Success#87 MediaWiki-Tests-Misc Failed#142-Failed#144 MediaWiki-Tests-Parser Failed#361-Success#363 So we need to do a better fingerprinting :-D
Assigning to self. We need that fixed ASAP since that confuse people and make the system hard to use.
jeblair suggests using BUILD_TAG env variable too :)
Jenkins somehow refuse to take finger print of .git/FETCH_HEAD which does not help either. We need a better script to take fingerprint which will include the gerrit patch number and the date of submission. So mostly known issue, need sometime to implement it.
Once Zuul is deployed we will no more have to take fingerprints to track job dependencies. Zuul update the job description to list job dependencies. Marking this as wontfix.
