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

Poll SCM Schedule form validation is wrong for @hourly, @daily

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • core
    • None
    • jenkins 1.642.1

      After entering a schedule such as @hourly or @daily in the "Poll SCM" (SCMTrigger) field the form validation reports when it would have last run and will next run. The times that it reports however appear to be different from the times that the SCM is actually polled. The times for "Build Periodically" (TimerTrigger) appear to be correct.

      I have created a job called "TestCron" and that shows different times for Poll SCM and Build Periodically (see screenshot). It appears to me that these should both be the same as they are based on the hash of the item name.

        1. PollSCMScheduleValidation.PNG
          PollSCMScheduleValidation.PNG
          24 kB

          [JENKINS-32805] Poll SCM Schedule form validation is wrong for @hourly, @daily

          Russell Gallop created issue -

          Russell Gallop added a comment - - edited

          In TimerTrigger.java the check is implemented by:

                  public FormValidation doCheckSpec(@QueryParameter String value, @AncestorInPath Item item) {
            try {
                CronTabList ctl = CronTabList.create(fixNull(value), item != null ? Hash.from(item.getFullName()) : null);

          which I guess is finding the name of the item in the URL for the hash.

          It looks like "Build Periodically" is using the checkUrl:http://<jenkins>/job/TestCron/descriptorByName/hudson.triggers.TimerTrigger/checkSpec?value=%40daily but "Poll SCM" is using http://<jenkins>/trigger/TimerTrigger/check?value=%40daily.

          So Poll SCM is probably unable to find the item name in the URL so initialises the hash with null and generates the previous and next times for that. This matches up with the fact that changing the job name affects the periodic schedule but not the SCM schedule (which is 0 apart from the seconds).

          Russell Gallop added a comment - - edited In TimerTrigger.java the check is implemented by: public FormValidation doCheckSpec(@QueryParameter String value, @AncestorInPath Item item) { try { CronTabList ctl = CronTabList.create(fixNull(value), item != null ? Hash.from(item.getFullName()) : null ); which I guess is finding the name of the item in the URL for the hash. It looks like "Build Periodically" is using the checkUrl: http://<jenkins>/job/TestCron/descriptorByName/hudson.triggers.TimerTrigger/checkSpec?value=%40daily but "Poll SCM" is using http://<jenkins>/trigger/TimerTrigger/check?value=%40daily . So Poll SCM is probably unable to find the item name in the URL so initialises the hash with null and generates the previous and next times for that. This matches up with the fact that changing the job name affects the periodic schedule but not the SCM schedule (which is 0 apart from the seconds).
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 168471 ] New: JNJira + In-Review [ 183147 ]

          Daniel Beck added a comment -

          Resolved as JENKINS-26977 earlier this year.

          Daniel Beck added a comment - Resolved as JENKINS-26977 earlier this year.
          Daniel Beck made changes -
          Link New: This issue duplicates JENKINS-26977 [ JENKINS-26977 ]
          Daniel Beck made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

            Unassigned Unassigned
            rg Russell Gallop
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: