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

Javadoc publishing fails on consecutive successful builds

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Hudson 1.355, Windows Server 2008

      I am having the problem that Javadoc publishing fails after the first successful build. That is, build #1 succeeds and publishes Javadoc, but build #2 onwards fails with the following error:

      ERROR: No javadoc found in C:\Program Files\Hudson\jobs\FLTools\workspace\docs/api/html: null

      I found however that after deleting the published Javadoc directory, C:\Program Files\Hudson\jobs\FLTools\javadoc, the build succeeds again. Therefore, it looks like Hudson is having problems overwriting previously published Javadoc.

          [JENKINS-6332] Javadoc publishing fails on consecutive successful builds

          Alan Harder added a comment -

          This will happen if the javadoc directory in your job's workspace is exactly the same as it was for the previous build (ie, there is nothing new to copy..). Does your job skip javadoc generation when it sees javadoc from a previous run? Can you do a "clean" build to force javadoc to run again?

          Alan Harder added a comment - This will happen if the javadoc directory in your job's workspace is exactly the same as it was for the previous build (ie, there is nothing new to copy..). Does your job skip javadoc generation when it sees javadoc from a previous run? Can you do a "clean" build to force javadoc to run again?

          Arve Knudsen added a comment -

          The buildsystem only regenerates the API documentation if the sources have changed, as one would expect?? Are you saying it's a feature of Hudson to break the build if the Javadoc hasn't changed since last time? I could of course force regeneration of the docs, but I'd rather see the bug fixed (unless it's considered a feature??).

          Arve Knudsen added a comment - The buildsystem only regenerates the API documentation if the sources have changed, as one would expect?? Are you saying it's a feature of Hudson to break the build if the Javadoc hasn't changed since last time? I could of course force regeneration of the docs, but I'd rather see the bug fixed (unless it's considered a feature??).

          Alan Harder added a comment -

          Not a feature, just a side-effect of the code interpreting "zero files copied" as a configuration or communication error.. it doesn't distinguish this from "all files were already current". I think the common usage is to have Hudson run clean builds each time, so this issue hasn't come up before.. so I'd consider it a lower priority item (a patch to fix it is welcome, of course )

          Alan Harder added a comment - Not a feature, just a side-effect of the code interpreting "zero files copied" as a configuration or communication error.. it doesn't distinguish this from "all files were already current". I think the common usage is to have Hudson run clean builds each time, so this issue hasn't come up before.. so I'd consider it a lower priority item (a patch to fix it is welcome, of course )

          Arve Knudsen added a comment -

          It sounds weird to me, coming from Buildbot, that the common case is to perform clean builds each time? That can really slow down the time taken to verify a checkin, which doesn't seem like what you want. In Buildbot the typical job builds incrementally while you typically have a nightly job that does a clean checkout and does more in-depth checking. I'll have my job clean the Javadoc though before building, as a workaround.

          Arve Knudsen added a comment - It sounds weird to me, coming from Buildbot, that the common case is to perform clean builds each time? That can really slow down the time taken to verify a checkin, which doesn't seem like what you want. In Buildbot the typical job builds incrementally while you typically have a nightly job that does a clean checkout and does more in-depth checking. I'll have my job clean the Javadoc though before building, as a workaround.

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/core/src/main/java/hudson/FilePath.java
          trunk/hudson/main/core/src/test/java/hudson/FilePathTest.java
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/30450
          Log:
          [FIXED JENKINS-6332] for 1.357
          Add setOverwrite(true) for local->local copy in FilePath.copyRecursiveTo().
          This makes it consistent with master/slave copy (either direction),
          and also avoids returning 0 if all files already have current/newer timestamp
          which some code (javadoc publishing, copyartifact plugin) would interpret as
          copy failure or no matching files found.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/java/hudson/FilePath.java trunk/hudson/main/core/src/test/java/hudson/FilePathTest.java trunk/www/changelog.html http://jenkins-ci.org/commit/30450 Log: [FIXED JENKINS-6332] for 1.357 Add setOverwrite(true) for local->local copy in FilePath.copyRecursiveTo(). This makes it consistent with master/slave copy (either direction), and also avoids returning 0 if all files already have current/newer timestamp which some code (javadoc publishing, copyartifact plugin) would interpret as copy failure or no matching files found.

            mindless Alan Harder
            aknuds1 Arve Knudsen
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: