• Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • core
    • None
    • Jenkins v1.486, Windows 7 64bit

      The URL of the build number (http://JENKINS/job/JOBNAME/BUILD_NR/) in the email notification of failed builds leads to Status code 404 page. However, if you remove the build number and click on the job page on the build number then this side is available and you notice that before visiting the side the link to that build number is already marked as visited.

          [JENKINS-15589] build URL in failed emails is broken

          robsimon added a comment - - edited

          The URL only works when the job page has been visited before. Could this be related to the lazy load?

          robsimon added a comment - - edited The URL only works when the job page has been visited before. Could this be related to the lazy load?

          Jason Swager added a comment -

          We've noticed the same behavior: Jenkins v1.491 since upgrading from 1.484. We found another workaround - hit some page that list the jobs whose builds can't be accessed via direct URL. I suppose we could browse all jobs upon Jenkins startup to ensure this URL jumping behavior works correctly. But it would be much better if it just worked properly.

          Jason Swager added a comment - We've noticed the same behavior: Jenkins v1.491 since upgrading from 1.484. We found another workaround - hit some page that list the jobs whose builds can't be accessed via direct URL. I suppose we could browse all jobs upon Jenkins startup to ensure this URL jumping behavior works correctly. But it would be much better if it just worked properly.

          I'm marking this bug as closed as a duplicate of JENKINS-15587.

          Accessing the build via URL does trigger the lazy loading (in fact there's no way to access any build without trigering a loading). Then later through other code path you manage to have the build in question loaded.

          So the only plausible explanation that I have is that one is using symlinks, and the other was using build ID to load. On symlink-enabled Windows, the former would hit JENKINS-15587, while the latter doesn't.

          Kohsuke Kawaguchi added a comment - I'm marking this bug as closed as a duplicate of JENKINS-15587 . Accessing the build via URL does trigger the lazy loading (in fact there's no way to access any build without trigering a loading). Then later through other code path you manage to have the build in question loaded. So the only plausible explanation that I have is that one is using symlinks, and the other was using build ID to load. On symlink-enabled Windows, the former would hit JENKINS-15587 , while the latter doesn't.

            kohsuke Kohsuke Kawaguchi
            robsimon robsimon
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: