Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18437

Config spec in snapshot view with "time" element always polls as "changes found"

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • clearcase-plugin
    • None

      Is it possible JENKINS-15202 has been re-introduced in 1.3.14 (possibly earlier)? I am using a snapshot view, with a time-based config spec. The clearcase polling log is shown below:
      Started on Jun 20, 2013 1:30:25 PM
      get view CSPEC ***********************
      [PSoC-Programmer-Build] $ cleartool catcs -tag Jenkins_build_CMSBUILD6.cms.cypress.com_PSoC-Programmer-Build
      time 20-Jun-13.13:20:25
      element * CHECKEDOUT
      element * .../main_pp319/LATEST
      element * PP3.18_B1534
      element * /main/LATEST
      load \ps1_swtools\Source
      ******************************************************************
      [WARNING] CSPEC configured != catcs (view)
      REASON: New config spec detected.
      Done. Took 0.47 sec
      Changes found

      The ClearCase poll ALWAYS results in "Changes found" since the timestamp is different than the last poll. I believe this to be the same issue noted in JENKINS-15202 (marked as fixed).

          [JENKINS-18437] Config spec in snapshot view with "time" element always polls as "changes found"

          mkinnari added a comment -

          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.

          mkinnari added a comment - 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.

            Unassigned Unassigned
            ster Gary Sterling
            Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: