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

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Duplicate
    • Component/s: core
    • Labels:
      None
    • Environment:
      jenkins 1.642.1
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            rg 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).

            Show
            rg 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).
            Hide
            danielbeck Daniel Beck added a comment -

            Resolved as JENKINS-26977 earlier this year.

            Show
            danielbeck Daniel Beck added a comment - Resolved as JENKINS-26977 earlier this year.

              People

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

                Dates

                Created:
                Updated:
                Resolved: