A few clarifying details on this issue:
-With our workflow, we use snapshot views on the build machine, with the config spec specified in the job configuration.
-For Jenkins builds, we use a time rule in the config spec, set to the time the build starts. This is done with the Jenkins BUILD_ID variable, using the ZenTimestamp plugin to adjust the formatting to be compatible with the time rule, so there's a line in the config spec that reads "time ${BUILD_ID}".
-We use the time rule to make sure we can easily reproduce any given build with 100% accuracy. The build script will record the config spec (via catcs), and store it as an artifact. If I want to reproduce the exact code used for any given build, I can take the config spec artifact, and load it into a view. Without the time rule, I'd just be getting the latest version.
Looking at the plugin code a bit, it appears that the problem is the logic in compareRemoteRevisionWith(). If it sees that the config spec has changed (which will always be the case, since ${BUILD_ID} will always expand to a different timestamp), then it returns PollingResult.BUILD_NOW, end of story. It looks like the issue was fixed for dynamic views for JENKINS-15202 by having time-based config specs return false for hasNewConfigSpec().
This could be fixed by NOT automatically triggering a new build when the config spec has changed, and just sticking with looking for changes in the repository. I'm having trouble trying to think up a workflow where the automatic build on config spec change would be useful. I would expect that changes to the config spec, other than minor things like this, would be done manually. In that case, the user making the change would probably just hit the "Build now" button afterwards. If removing the automatic behavior outright is a concern, then at least put an option in the GUI to disable it. As it is now, we're just doing builds several times a day on a schedule, whether or not there are any changes.
A few clarifying details on this issue:
-With our workflow, we use snapshot views on the build machine, with the config spec specified in the job configuration.
-For Jenkins builds, we use a time rule in the config spec, set to the time the build starts. This is done with the Jenkins BUILD_ID variable, using the ZenTimestamp plugin to adjust the formatting to be compatible with the time rule, so there's a line in the config spec that reads "time ${BUILD_ID}".
-We use the time rule to make sure we can easily reproduce any given build with 100% accuracy. The build script will record the config spec (via catcs), and store it as an artifact. If I want to reproduce the exact code used for any given build, I can take the config spec artifact, and load it into a view. Without the time rule, I'd just be getting the latest version.
Looking at the plugin code a bit, it appears that the problem is the logic in compareRemoteRevisionWith(). If it sees that the config spec has changed (which will always be the case, since ${BUILD_ID} will always expand to a different timestamp), then it returns PollingResult.BUILD_NOW, end of story. It looks like the issue was fixed for dynamic views for
JENKINS-15202by having time-based config specs return false for hasNewConfigSpec().This could be fixed by NOT automatically triggering a new build when the config spec has changed, and just sticking with looking for changes in the repository. I'm having trouble trying to think up a workflow where the automatic build on config spec change would be useful. I would expect that changes to the config spec, other than minor things like this, would be done manually. In that case, the user making the change would probably just hit the "Build now" button afterwards. If removing the automatic behavior outright is a concern, then at least put an option in the GUI to disable it. As it is now, we're just doing builds several times a day on a schedule, whether or not there are any changes.