|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
I like your idea Morne Joubert, but that still seems more reactive. The nightly build has already failed, and now users that needed that build are on standby waiting while analysis is being done to figure out which change caused the problem. In the approach I described above there are two separate Jenkins projects; one that triggers each time a change is submitted (an incremental build) and one that triggers nightly (a full build). The old Perforce plugin had an environment variable (P4ONECHANGELIST) that when set to true tells Jenkins to use the next changes after the one that was last built (as opposed to the head revision). This was set to true for the incremental builds and ensures that each build is just for one change so there is less ambiguity when the build fails (it's either the fault of the author of the change or the fault of the build system). We are not worried about the extra build time required to do it this way b/c right now we have a lot of idle build servers.