4

I have a Hudson server that runs maven 3 jobs to compile Java code. In one instance, a particular job's build log indicates that the compilation and unit tests all ran successfully, and the build completed in a successful state and another chained job was called, all indicated that Hudson believed the job to be successful. The log shows:

20:44:11  [INFO] BUILD SUCCESS
20:44:11  [INFO] ------------------------------------------------------------------------
20:44:11  [INFO] Total time: 1:35:43.774s
20:44:11  [INFO] Finished at: Mon Mar 24 20:44:11 CDT 2014
20:44:40  [INFO] Final Memory: 51M/495M
20:44:40  [INFO] ------------------------------------------------------------------------
20:44:42  channel stopped
20:44:42  [locks-and-latches] Releasing all the locks
20:44:42  [locks-and-latches] All the locks released
20:44:43  Archiving artifacts
20:45:33  Updating JIRA-1234
20:45:33  Description set: 1.23.567
20:45:33  Labelling Build in Perforce using ${BUILD_TAG}
20:45:33  [jobname] $ /usr/local/bin/p4 -s label -i
20:45:33  Label 'hudson-jobname-45' successfully generated.
20:45:33  [DEBUG] Skipping watched dependency update; build not configured with trigger:     jobname #45
20:45:33  Finished: SUCCESS

However, the Hudson job page shows a "red ball" and that job run is listed as "Last failed build (#45)" on the job page. When I look at the hudson@hudson:~hudson/jobs/jobname/builds/45/build.xml file, there is a line that says 

<result>FAILURE</result>

Assuming this was where the final result was captured, I changed this to 

<result>SUCCESS</result>

and reloaded the page, but the red ball is still showing on the job page for that instance. I have not restarted the server to attempt to re-read the info from disk.

To be fair, there were some environmental issues around this build. Some hours later, I got a message that more than one Hudson server instance was running against the same disk image and confirmed this with 

ps -ef | grep hudson.war

on the server console, showing two running processes. The job page says this run "Took 0 ms", even though the log says "Total time: 1:35:43.774s". This is Hudson ver. 2.2.1 running on "CentOS release 5.4 (Final)".

My questions:

  1. What are the criteria for each of the job statuses? (Stable, Failed, Unstable, Aborted and Disabled statuses)?
  2. When and where is that data captured in the running server, and can it be modified?
Codex24
  • 323
  • 1
  • 5
  • 14

2 Answers2

3

You have too many questions in one post.

As for "What are the criteria for each of the job statuses? (Stable, Failed, Unstable, Aborted and Disabled statuses)?"

  • Disabled is when a project/job is disabled from configuration (done by user with permissions). This is not a run status.

The rest are Job Run statuses:

  • Aborted is when a run has been cancelled/aborted. This happens when a user (with permissions) clicks the red cross button to cancel a running build. I believe SCM checkout failure also causes aborted status (but not too sure about that)
  • Unstable is a special status that can be applied to the job run. Usually this is done by job configuration (such as Maven) or through plugins such as Text-finder plugin. I am not aware of a way to induce unstable status through command line. Maybe through a groovy script, like plugins do. Most of the times, unstable is set by the job configuration itself, indicating failed test.
  • Stable and Failed are the direct result of Build Step's exit code. If the build step, such as Execute Shell, exits with exit code 0, the build step is considered success. Anything other than 0 is considered failed. If during execution of a build step, the process exits with anything other than 0, it is considered failed. If there are multiple build steps (Free-style project jobs), the last Build Step's exit code marks the status of the whole run. Once again, any Build Step in between that exits with anything other than 0 will mark the build failed.
  • Post-build actions, such as Text-finder plugin can also change the status of the job run.

You are not supposed to be tinkering with job history files to change the status of previous jobs. If you need to change the job result, use post-build actions such as Text-finder plugin, but even then, it only allows to downgrade the result.

Slav
  • 27,057
  • 11
  • 80
  • 104
  • 1
    When I asked, "What are the criteria for each of the job statuses?", I was not asking how they should be interpreted by humans, but how they were defined and detected by the Hudson program. From the messages, it would appear that the job run in question had a 0 exit code, but something flagged the run as "failed" in the metadata. Why? How can this be corrected after the fact? – Codex24 Jul 08 '14 at 23:11
  • `0` - success, `1 and all else` - failure. That is as far as the **build step result** is concerned. After that, there are many **post-build actions** which can affect the status of the job run, including marking it failed. I did mention that in my asnwer – Slav Jul 09 '14 at 14:25
  • So the build run (probably) had an 0 exit code, and some post-processing, most likely text matching-based, downgraded the success to failure. How can the specific failure criteria be identified? If faulty, how can the result be manually corrected for that run? That is, not considering the real fix to prevent regression: changing configuration and re-running the job. – Codex24 Jul 09 '14 at 15:09
  • Is that the whole log (from the bottom)? If a post-build action marks a build as failed, there is usually some indication in the log. From your log, looks like success after all post-build actions. – Slav Jul 10 '14 at 04:21
-2

Here's a one liner to printing the commit SHA1 in a jenkins job using groovy post-build script:

println "git rev-parse HEAD".execute().text

You can save this to a variable or export it as a build parameter.

Sushant Bose
  • 1
  • 1