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

crap4j plugin does not mark job failed correctly on parse failure, later post-build steps still run

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • crap4j-plugin
    • None

      Was previously summarized as:

      Git Plugin Publisher Publishes on Failed Build even though set to push only if build succeeds

      Git Publisher, but the task is getting run even though a part failed. (As a note, a Post build task runs as well so I'm thinking some variable use must have changed over time.)

      Here is the output:
      CRAP4J fails as you can see, but push runs. Then, at the end the build is labeled a failure. I'm attaching a screenshot of the configuration.

      build:

      BUILD SUCCESSFUL
      Total time: 1 minute 23 seconds
      [CHECKSTYLE] Collecting checkstyle analysis files...
      [CHECKSTYLE] Finding all files that match the pattern build/logs/checkstyle.xml
      [CHECKSTYLE] Parsing 1 files in /var/lib/jenkins/workspace/SBTS Portal
      [CHECKSTYLE] Successfully parsed file /var/lib/jenkins/workspace/SBTS Portal/build/logs/checkstyle.xml of module with 253 warnings.
      [CHECKSTYLE] Computing warning deltas based on reference build #108
      [PMD] Collecting PMD analysis files...
      [PMD] Finding all files that match the pattern build/logs/pmd.xml
      [PMD] Parsing 1 files in /var/lib/jenkins/workspace/SBTS Portal
      [PMD] Successfully parsed file /var/lib/jenkins/workspace/SBTS Portal/build/logs/pmd.xml of module with 8 warnings.
      [PMD] Computing warning deltas based on reference build #108
      [DRY] Collecting duplicate code analysis files...
      [DRY] Finding all files that match the pattern build/logs/pmd-cpd.xml
      [DRY] Parsing 1 files in /var/lib/jenkins/workspace/SBTS Portal
      [DRY] Successfully parsed file /var/lib/jenkins/workspace/SBTS Portal/build/logs/pmd-cpd.xml of module with 36 warnings.
      [DRY] Computing warning deltas based on reference build #108
      Recording plot data
      Publishing Clover coverage report...
      Clover xml file does not exist in: /var/lib/jenkins/workspace/SBTS Portal called: build/logs/clover.xml and will not be copied to: /var/lib/jenkins/jobs/SBTS Portal/builds/2014-09-23_15-43-35/cloverphp/clover.xml
      Could not find 'build/coverage/build/logs/clover.xml'. Did you generate the XML report for Clover?
      [CRAP4J] Collecting Crap4J analysis files...
      [CRAP4J] Searching for report files within build/logs/crap4j.xml
      [CRAP4J] Using the new FileSetBuilder
      [CRAP4J] No crap4j report files were found. Configuration error?
      Build step 'Report Crap' marked build as failure
      [htmlpublisher] Archiving HTML reports...
      [htmlpublisher] Archiving at BUILD level /var/lib/jenkins/workspace/SBTS Portal/build/api to /var/lib/jenkins/jobs/SBTS Portal/builds/2014-09-23_15-43-35/htmlreports/API_Documentation
      [htmlpublisher] Archiving at BUILD level /var/lib/jenkins/workspace/SBTS Portal/build/phpdoc to /var/lib/jenkins/jobs/SBTS Portal/builds/2014-09-23_15-43-35/htmlreports/PHPDoc_Documentation
      [xUnit] [INFO] - Starting to record.
      [xUnit] [INFO] - Processing PHPUnit-3.x (default)
      [xUnit] [INFO] - [PHPUnit-3.x (default)] - 1 test report file(s) were found with the pattern 'build/logs/junit.xml' relative to '/var/lib/jenkins/workspace/SBTS Portal' for the testing framework 'PHPUnit-3.x (default)'.
      [xUnit] [INFO] - Converting '/var/lib/jenkins/workspace/SBTS Portal/build/logs/junit.xml' .
      [xUnit] [INFO] - Check 'Failed Tests' threshold.
      [xUnit] [INFO] - Check 'Skipped Tests' threshold.
      [xUnit] [INFO] - Setting the build status to SUCCESS
      [xUnit] [INFO] - Stopping recording.
      [JDepend] JDepend plugin is ready
      [JDepend] Found 273 classes in 21 packages
      Performing Post build task...
      Match found for : : True
      Logical operation result is TRUE
      Running script : git add --all ./build/api
      git commit -m "Jenkins Updating Doc Files"
      [SBTS Portal] $ /bin/sh -xe /tmp/hudson3629220943294003302.sh
      + git add --all ./build/api
      + git commit -m Jenkins Updating Doc Files
      [detached HEAD 42c8f11] Jenkins Updating Doc Files
      1 file changed, 1 insertion, 1 deletion
      POST BUILD TASK : SUCCESS
      END OF POST BUILD TASK : 0
      > git tag -l jenkins-SBTS_Portal-111 # timeout=10
      > git tag -a -f -m Jenkins Build #111 jenkins-SBTS_Portal-111-SUCCESS # timeout=10
      Pushing HEAD to branch develop of origin repository
      > git push — HEAD:develop
      Checking for post-build
      Performing post-build step
      Checking if email needs to be generated
      Email was triggered for: Failure - Any
      Sending email for trigger: Failure - Any
      NOT overriding default server settings, using Mailer to create session
      messageContentType = text/plain; charset=UTF-8
      Adding recipients from project recipient list

      Successfully created MimeMessage
      Sending email to: ----
      Finished: FAILURE

        1. Screen Shot 2014-09-23 at 4.34.48 PM.png
          Screen Shot 2014-09-23 at 4.34.48 PM.png
          46 kB

          [JENKINS-24833] crap4j plugin does not mark job failed correctly on parse failure, later post-build steps still run

          Mark Waite added a comment - - edited

          It appears from the screen shot that you upgraded from a git 1.x release to git plugin 2.2.6. That may indicate that you need to make some minor change to the job definition, and save it. That minor change and save may switch the job configuration file from using the git plugin 1.x settings to using the latest settings.

          Sorry for this junk comment. I confused this bug report with a completely different bug report. I'll need to stare at this more before I say anything else foolish.

          Mark Waite added a comment - - edited It appears from the screen shot that you upgraded from a git 1.x release to git plugin 2.2.6. That may indicate that you need to make some minor change to the job definition, and save it. That minor change and save may switch the job configuration file from using the git plugin 1.x settings to using the latest settings. Sorry for this junk comment. I confused this bug report with a completely different bug report. I'll need to stare at this more before I say anything else foolish.

          Loren Klingman added a comment -

          That's a strange thing to have happened. I just added the git merge pushing a day or two ago so the job details should have been up to date. I also installed some plugin updates at that time, but I stay pretty up to date on the plugins so I don't think I would have gone from 1.x to 2.2.6. When I originally configured this job and installed Jenkins in July or August, I did start with a sample job configuration file so if I have old settings, more than likely they came from that file rather than from something I had installed.
          I just resaved is there something I should be looking to change on the configuration page?

          Loren Klingman added a comment - That's a strange thing to have happened. I just added the git merge pushing a day or two ago so the job details should have been up to date. I also installed some plugin updates at that time, but I stay pretty up to date on the plugins so I don't think I would have gone from 1.x to 2.2.6. When I originally configured this job and installed Jenkins in July or August, I did start with a sample job configuration file so if I have old settings, more than likely they came from that file rather than from something I had installed. I just resaved is there something I should be looking to change on the configuration page?

          Mark Waite added a comment -

          wiseloren I tried to duplicate the problem you're seeing with a smaller case and couldn't. Could you attempt to narrow the failure mode further?

          I tried:

          1. Create a freestyle job JENKINS-24833-git-publishes-always
          2. Configure it to use a git repository
          3. Add an XShell build step "python add_a_file.py" which runs a python script to add a file to the repo
          4. Add a git publisher step to push to the origin remote, master branch
          5. Confirm that job succeeds and the change is pushed
          6. Add a failing build step after the XShell build step (I used XShell with the command "false" and I used a call to ant)
          7. Confirm that job fails and the change is not pushed

          I also tried a variation:

          1. Add a failing post build action (I used publish JUnit reports when the job has no JUnit results)

          Mark Waite added a comment - wiseloren I tried to duplicate the problem you're seeing with a smaller case and couldn't. Could you attempt to narrow the failure mode further? I tried: Create a freestyle job JENKINS-24833 -git-publishes-always Configure it to use a git repository Add an XShell build step "python add_a_file.py" which runs a python script to add a file to the repo Add a git publisher step to push to the origin remote, master branch Confirm that job succeeds and the change is pushed Add a failing build step after the XShell build step (I used XShell with the command "false" and I used a call to ant) Confirm that job fails and the change is not pushed I also tried a variation: Add a failing post build action (I used publish JUnit reports when the job has no JUnit results)

          Loren Klingman added a comment - - edited

          Is build status case sensitive in your check? I have two post-build failures that I tried.

          In both cases, Jenkins recognizes a job failure, but only in one case does the push not happen. The main difference I'm noticing is that CRAP4J marks it as failure not FAILURE. Thus, I'm thinking Jenkins must be case insensitive where the other plugins are case sensitive. (Your plugin isn't the only one missing the marking as a failure there.) If that is the case, I'll submit a bug request to CRAP4J (though it might be good for your check to be case insensitive since jenkins is).

          One is with xUnit

          Building in workspace /var/lib/jenkins/workspace/Test
          > git rev-parse --is-inside-work-tree # timeout=10
          Fetching changes from the remote Git repository
          > git config remote.origin.url git@bitbucket.org:wiseloren/finance.git # timeout=10
          Fetching upstream changes from git@bitbucket.org:wiseloren/finance.git
          > git --version # timeout=10
          > git fetch --tags --progress git@bitbucket.org:wiseloren/finance.git +refs/heads/:refs/remotes/origin/
          > git rev-parse refs/remotes/origin/develop^

          {commit} # timeout=10
          > git rev-parse refs/remotes/origin/origin/develop^{commit}

          # timeout=10
          Checking out Revision 7553bf2bc81d6086400b9274e52e806e5fc90374 (refs/remotes/origin/develop)
          > git config core.sparsecheckout # timeout=10
          > git checkout -f 7553bf2bc81d6086400b9274e52e806e5fc90374
          > git rev-list 7553bf2bc81d6086400b9274e52e806e5fc90374 # timeout=10
          [Test] $ /bin/sh -xe /tmp/hudson4989245979488022036.sh
          + date
          + git add date.txt
          + git commit -m test
          [detached HEAD f3d92b4] test
          1 file changed, 1 insertion, 1 deletion
          [xUnit] [INFO] - Starting to record.
          [xUnit] [INFO] - Processing PHPUnit-3.x (default)
          [xUnit] [INFO] - [PHPUnit-3.x (default)] - 1 test report file(s) were found with the pattern 'build/logs/junit.xml' relative to '/var/lib/jenkins/workspace/Test' for the testing framework 'PHPUnit-3.x (default)'.
          [xUnit] [ERROR] - Test reports were found but not all of them are new. Did all the tests run?

          • /var/lib/jenkins/workspace/Test/build/logs/junit.xml is 1 min 41 sec old

          [xUnit] [INFO] - Failing BUILD.
          [xUnit] [INFO] - There are errors when processing test results.
          [xUnit] [INFO] - Skipping tests recording.
          [xUnit] [INFO] - Stop build.
          Build step 'Publish xUnit test result report' changed build result to FAILURE
          Build did not succeed and the project is configured to only push after a successful build, so no pushing will occur.
          Finished: FAILURE

          The other is with Crap4J

          Building in workspace /var/lib/jenkins/workspace/Test
          > git rev-parse --is-inside-work-tree # timeout=10
          Fetching changes from the remote Git repository
          > git config remote.origin.url git@bitbucket.org:wiseloren/finance.git # timeout=10
          Fetching upstream changes from git@bitbucket.org:wiseloren/finance.git
          > git --version # timeout=10
          > git fetch --tags --progress git@bitbucket.org:wiseloren/finance.git +refs/heads/:refs/remotes/origin/
          > git rev-parse refs/remotes/origin/develop^

          {commit} # timeout=10
          > git rev-parse refs/remotes/origin/origin/develop^{commit}

          # timeout=10
          Checking out Revision 7553bf2bc81d6086400b9274e52e806e5fc90374 (refs/remotes/origin/develop)
          > git config core.sparsecheckout # timeout=10
          > git checkout -f 7553bf2bc81d6086400b9274e52e806e5fc90374
          > git rev-list 7553bf2bc81d6086400b9274e52e806e5fc90374 # timeout=10
          [Test] $ /bin/sh -xe /tmp/hudson7046176554547474773.sh
          + date
          + git add date.txt
          + git commit -m test
          [detached HEAD 4f7619c] test
          1 file changed, 1 insertion, 1 deletion
          [CRAP4J] Collecting Crap4J analysis files...
          [CRAP4J] Searching for report files within build/logs/crap4j2.xml
          [CRAP4J] Using the new FileSetBuilder
          [CRAP4J] No crap4j report files were found. Configuration error?
          Build step 'Report Crap' marked build as failure
          Pushing HEAD to branch develop at repo origin
          > git push git@bitbucket.org:wiseloren/finance.git HEAD:develop
          Finished: FAILURE

          Loren Klingman added a comment - - edited Is build status case sensitive in your check? I have two post-build failures that I tried. In both cases, Jenkins recognizes a job failure, but only in one case does the push not happen. The main difference I'm noticing is that CRAP4J marks it as failure not FAILURE. Thus, I'm thinking Jenkins must be case insensitive where the other plugins are case sensitive. (Your plugin isn't the only one missing the marking as a failure there.) If that is the case, I'll submit a bug request to CRAP4J (though it might be good for your check to be case insensitive since jenkins is). One is with xUnit Building in workspace /var/lib/jenkins/workspace/Test > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url git@bitbucket.org:wiseloren/finance.git # timeout=10 Fetching upstream changes from git@bitbucket.org:wiseloren/finance.git > git --version # timeout=10 > git fetch --tags --progress git@bitbucket.org:wiseloren/finance.git +refs/heads/ :refs/remotes/origin/ > git rev-parse refs/remotes/origin/develop^ {commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10 Checking out Revision 7553bf2bc81d6086400b9274e52e806e5fc90374 (refs/remotes/origin/develop) > git config core.sparsecheckout # timeout=10 > git checkout -f 7553bf2bc81d6086400b9274e52e806e5fc90374 > git rev-list 7553bf2bc81d6086400b9274e52e806e5fc90374 # timeout=10 [Test] $ /bin/sh -xe /tmp/hudson4989245979488022036.sh + date + git add date.txt + git commit -m test [detached HEAD f3d92b4] test 1 file changed, 1 insertion , 1 deletion [xUnit] [INFO] - Starting to record. [xUnit] [INFO] - Processing PHPUnit-3.x (default) [xUnit] [INFO] - [PHPUnit-3.x (default)] - 1 test report file(s) were found with the pattern 'build/logs/junit.xml' relative to '/var/lib/jenkins/workspace/Test' for the testing framework 'PHPUnit-3.x (default)'. [xUnit] [ERROR] - Test reports were found but not all of them are new. Did all the tests run? /var/lib/jenkins/workspace/Test/build/logs/junit.xml is 1 min 41 sec old [xUnit] [INFO] - Failing BUILD. [xUnit] [INFO] - There are errors when processing test results. [xUnit] [INFO] - Skipping tests recording. [xUnit] [INFO] - Stop build. Build step 'Publish xUnit test result report' changed build result to FAILURE Build did not succeed and the project is configured to only push after a successful build, so no pushing will occur. Finished: FAILURE The other is with Crap4J Building in workspace /var/lib/jenkins/workspace/Test > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url git@bitbucket.org:wiseloren/finance.git # timeout=10 Fetching upstream changes from git@bitbucket.org:wiseloren/finance.git > git --version # timeout=10 > git fetch --tags --progress git@bitbucket.org:wiseloren/finance.git +refs/heads/ :refs/remotes/origin/ > git rev-parse refs/remotes/origin/develop^ {commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10 Checking out Revision 7553bf2bc81d6086400b9274e52e806e5fc90374 (refs/remotes/origin/develop) > git config core.sparsecheckout # timeout=10 > git checkout -f 7553bf2bc81d6086400b9274e52e806e5fc90374 > git rev-list 7553bf2bc81d6086400b9274e52e806e5fc90374 # timeout=10 [Test] $ /bin/sh -xe /tmp/hudson7046176554547474773.sh + date + git add date.txt + git commit -m test [detached HEAD 4f7619c] test 1 file changed, 1 insertion , 1 deletion [CRAP4J] Collecting Crap4J analysis files... [CRAP4J] Searching for report files within build/logs/crap4j2.xml [CRAP4J] Using the new FileSetBuilder [CRAP4J] No crap4j report files were found. Configuration error? Build step 'Report Crap' marked build as failure Pushing HEAD to branch develop at repo origin > git push git@bitbucket.org:wiseloren/finance.git HEAD:develop Finished: FAILURE

          Mark Waite added a comment -

          With the xUnit plugin configured to publish JUnit type reports from my job which does not generate JUnit reports, I see that the build fails (as expected) and does not push to the remote git repository.

          Started by user Mark Waite
Building remotely on centos7x64 (7.0.1406 CentOS amd64-CentOS-7.0.1406 linux CentOS-7.0.1406 amd64-CentOS amd64) in workspace /var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git # timeout=10
Fetching upstream changes from ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git
 > git --version # timeout=10
using GIT_SSH to set credentials mwaite@mark-pc1
 > git fetch --tags --progress ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0
 > git rev-list 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 # timeout=10
[JENKINS-24833-git-publishes-always] $ python add_a_file.py
rm 'tmpoeSqtg'
[detached HEAD 852dcf5] Removed tmp fles
 1 file changed, 1 deletion(-)
 delete mode 100644 tmpoeSqtg
[detached HEAD cb0da15] Added /var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always/tmp3S20p6
 1 file changed, 1 insertion(+)
 create mode 100644 tmp3S20p6
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - No test report file(s) were found with the pattern '*.xml' relative to '/var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always' for the testing framework 'JUnit'.  Did you enter a pattern relative to the correct directory?  Did you generate the result report(s) for 'JUnit'?
[xUnit] [ERROR] - No test reports found for the metric 'JUnit' with the resolved pattern '*.xml'. Configuration error?.
[xUnit] [INFO] - Failing BUILD.
[xUnit] [INFO] - There are errors when processing test results.
[xUnit] [INFO] - Skipping tests recording.
[xUnit] [INFO] - Stop build.
Build step 'Process xUnit test result report' changed build result to FAILURE
Build did not succeed and the project is configured to only push after a successful build, so no pushing will occur.
Finished: FAILURE

          Mark Waite added a comment - With the xUnit plugin configured to publish JUnit type reports from my job which does not generate JUnit reports, I see that the build fails (as expected) and does not push to the remote git repository. Started by user Mark Waite Building remotely on centos7x64 (7.0.1406 CentOS amd64-CentOS-7.0.1406 linux CentOS-7.0.1406 amd64-CentOS amd64) in workspace /var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git # timeout=10 Fetching upstream changes from ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git > git --version # timeout=10 using GIT_SSH to set credentials mwaite@mark-pc1 > git fetch --tags --progress ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10 Checking out Revision 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 (refs/remotes/origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 > git rev-list 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 # timeout=10 [JENKINS-24833-git-publishes-always] $ python add_a_file.py rm 'tmpoeSqtg' [detached HEAD 852dcf5] Removed tmp fles 1 file changed, 1 deletion(-) delete mode 100644 tmpoeSqtg [detached HEAD cb0da15] Added /var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always/tmp3S20p6 1 file changed, 1 insertion(+) create mode 100644 tmp3S20p6 [xUnit] [INFO] - Starting to record. [xUnit] [INFO] - Processing JUnit [xUnit] [INFO] - [JUnit] - No test report file(s) were found with the pattern '*.xml' relative to '/var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always' for the testing framework 'JUnit'. Did you enter a pattern relative to the correct directory? Did you generate the result report(s) for 'JUnit'? [xUnit] [ERROR] - No test reports found for the metric 'JUnit' with the resolved pattern '*.xml'. Configuration error?. [xUnit] [INFO] - Failing BUILD. [xUnit] [INFO] - There are errors when processing test results. [xUnit] [INFO] - Skipping tests recording. [xUnit] [INFO] - Stop build. Build step 'Process xUnit test result report' changed build result to FAILURE Build did not succeed and the project is configured to only push after a successful build, so no pushing will occur. Finished: FAILURE

          Mark Waite added a comment -

          With the Crap4J plugin, I can see that the build is reported as a failure, but the git publisher still pushes the changes.

          I don't know if that is expected or not, since both the Git publisher and Crap4J are post build actions. I'll need to ask on the mailing list for the expected behavior of post-build actions when one of the post-build actions fails.

          As an example of the potential conflict between the results of post-build actions, if 3 post-build actions are defined on a job, and the first action succeeds, but the second action fails, should the job be considered failed? In my case the job was marked as failed.

          If the first action succeeds and the second action fails, should the third action be executed at all? In my case, there were 2 post-build actions. The log seems to indicate that the Crap4J action may have finished before the git publisher action, though I can't be absolutely sure. In my case, I believe the Crap4J action was first and caused the job to be marked as failed, but did not cause the publisher push to be stopped.

          Started by user Mark Waite
Building remotely on centos7x64 (7.0.1406 CentOS amd64-CentOS-7.0.1406 linux CentOS-7.0.1406 amd64-CentOS amd64) in workspace /var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git # timeout=10
Fetching upstream changes from ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git
 > git --version # timeout=10
using GIT_SSH to set credentials mwaite@mark-pc1
 > git fetch --tags --progress ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0
 > git rev-list 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 # timeout=10
[JENKINS-24833-git-publishes-always] $ python add_a_file.py
rm 'tmpoeSqtg'
[detached HEAD b1c7ef1] Removed tmp fles
 1 file changed, 1 deletion(-)
 delete mode 100644 tmpoeSqtg
[detached HEAD 529312a] Added /var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always/tmpyFk42u
 1 file changed, 1 insertion(+)
 create mode 100644 tmpyFk42u
[CRAP4J] Collecting Crap4J analysis files...
[CRAP4J] Searching for report files within *.xml
[CRAP4J] Using the new FileSetBuilder
[CRAP4J] No crap4j report files were found. Configuration error?
Build step 'Report Crap' marked build as failure
Pushing HEAD to branch master at repo origin
using GIT_SSH to set credentials mwaite@mark-pc1
 > git push ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git HEAD:master
Finished: FAILURE

          Mark Waite added a comment - With the Crap4J plugin, I can see that the build is reported as a failure, but the git publisher still pushes the changes. I don't know if that is expected or not, since both the Git publisher and Crap4J are post build actions. I'll need to ask on the mailing list for the expected behavior of post-build actions when one of the post-build actions fails. As an example of the potential conflict between the results of post-build actions, if 3 post-build actions are defined on a job, and the first action succeeds, but the second action fails, should the job be considered failed? In my case the job was marked as failed. If the first action succeeds and the second action fails, should the third action be executed at all? In my case, there were 2 post-build actions. The log seems to indicate that the Crap4J action may have finished before the git publisher action, though I can't be absolutely sure. In my case, I believe the Crap4J action was first and caused the job to be marked as failed, but did not cause the publisher push to be stopped. Started by user Mark Waite Building remotely on centos7x64 (7.0.1406 CentOS amd64-CentOS-7.0.1406 linux CentOS-7.0.1406 amd64-CentOS amd64) in workspace /var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git # timeout=10 Fetching upstream changes from ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git > git --version # timeout=10 using GIT_SSH to set credentials mwaite@mark-pc1 > git fetch --tags --progress ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10 Checking out Revision 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 (refs/remotes/origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 > git rev-list 0ac1e6fd10414a191c58f6fb0a6cb11c90644ea0 # timeout=10 [JENKINS-24833-git-publishes-always] $ python add_a_file.py rm 'tmpoeSqtg' [detached HEAD b1c7ef1] Removed tmp fles 1 file changed, 1 deletion(-) delete mode 100644 tmpoeSqtg [detached HEAD 529312a] Added /var/lib/jenkins/mark-pc1-slave/workspace/JENKINS-24833-git-publishes-always/tmpyFk42u 1 file changed, 1 insertion(+) create mode 100644 tmpyFk42u [CRAP4J] Collecting Crap4J analysis files... [CRAP4J] Searching for report files within *.xml [CRAP4J] Using the new FileSetBuilder [CRAP4J] No crap4j report files were found. Configuration error? Build step 'Report Crap' marked build as failure Pushing HEAD to branch master at repo origin using GIT_SSH to set credentials mwaite@mark-pc1 > git push ssh://mwaite@mark-pc1/var/lib/git/mwaite/bugs/JENKINS-24833.git HEAD:master Finished: FAILURE

          Mark Waite added a comment -

          Based on a few more experiments with other post-build actions, the only case where I've detected that git publisher seems to consistently publish even on failed build is in the case of the Crap4J plugin. That may be a happy accident, but I checked other post-build actions like

          • JaCoCo results publisher
          • Findbugs results publisher
          • JUnit results publisher

          In each of those cases, the Git publisher reported that it would not push the results because the build failed.

          Mark Waite added a comment - Based on a few more experiments with other post-build actions, the only case where I've detected that git publisher seems to consistently publish even on failed build is in the case of the Crap4J plugin. That may be a happy accident, but I checked other post-build actions like JaCoCo results publisher Findbugs results publisher JUnit results publisher In each of those cases, the Git publisher reported that it would not push the results because the build failed.

          Loren Klingman added a comment -

          Digging through source code

          Crap4J returns false on failure https://svn.jenkins-ci.org/trunk/hudson/plugins/crap4j/src/main/java/hudson/plugins/crap4j/Crap4JPublisher.java
          if (0 == reports.length)

          { log(logger, "No crap4j report files were found. Configuration error?"); return false; }

          Where xUnit returns true and sets the build result to failure
          https://github.com/jenkinsci/xunit-plugin/blob/a0ad57db81ef5a91162dbfa7190a1a8bcb838edd/src/main/java/org/jenkinsci/plugins/xunit/XUnitProcessor.java#L83

          GitPublisher is looking at the build result:
          https://github.com/jenkinsci/git-plugin/blob/cebb9da131fa6c9e07ec9e6ff71ec89aa58fdd6f/src/main/java/hudson/plugins/git/GitPublisher.java#L203

          Theoretically the false result is canContinue:
          https://github.com/jenkinsci/jenkins/blob/a197999c6c57ad761f7242b9f6b28c0333175601/core/src/main/java/hudson/model/AbstractBuild.java#L781

          But in actuality all build steps run even if one fails (though a final result of false is reported):
          https://github.com/jenkinsci/jenkins/blob/a197999c6c57ad761f7242b9f6b28c0333175601/core/src/main/java/hudson/model/AbstractBuild.java#L724

          It looks like their is absolutely no way that git-publish could know that Crap4J failed unless Crap4J changes the build result like all the other plugins.

          Thanks for your help in testing things and helping me narrow this to a point that I could find the actual problem.

          I'll reference this in a Crap4J bug. I would try to fix it since it should be a one line change, but that plugin is still on an old SVN structure, and I'm not familiar with building Jenkins plugins from scratch.

          Loren Klingman added a comment - Digging through source code Crap4J returns false on failure https://svn.jenkins-ci.org/trunk/hudson/plugins/crap4j/src/main/java/hudson/plugins/crap4j/Crap4JPublisher.java if (0 == reports.length) { log(logger, "No crap4j report files were found. Configuration error?"); return false; } Where xUnit returns true and sets the build result to failure https://github.com/jenkinsci/xunit-plugin/blob/a0ad57db81ef5a91162dbfa7190a1a8bcb838edd/src/main/java/org/jenkinsci/plugins/xunit/XUnitProcessor.java#L83 GitPublisher is looking at the build result: https://github.com/jenkinsci/git-plugin/blob/cebb9da131fa6c9e07ec9e6ff71ec89aa58fdd6f/src/main/java/hudson/plugins/git/GitPublisher.java#L203 Theoretically the false result is canContinue: https://github.com/jenkinsci/jenkins/blob/a197999c6c57ad761f7242b9f6b28c0333175601/core/src/main/java/hudson/model/AbstractBuild.java#L781 But in actuality all build steps run even if one fails (though a final result of false is reported): https://github.com/jenkinsci/jenkins/blob/a197999c6c57ad761f7242b9f6b28c0333175601/core/src/main/java/hudson/model/AbstractBuild.java#L724 It looks like their is absolutely no way that git-publish could know that Crap4J failed unless Crap4J changes the build result like all the other plugins. Thanks for your help in testing things and helping me narrow this to a point that I could find the actual problem. I'll reference this in a Crap4J bug. I would try to fix it since it should be a one line change, but that plugin is still on an old SVN structure, and I'm not familiar with building Jenkins plugins from scratch.

            Unassigned Unassigned
            wiseloren Loren Klingman
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: