timja / jenkins-gh-issues-poc-06-18

0 stars 0 forks source link

[JENKINS-7083] "Trigger even if the build is unstable" does not work for free-style software project #850

Closed timja closed 14 years ago

timja commented 14 years ago

"Trigger even if the build is unstable" does not trigger the dependent projects when the build was unsuccessful for free-style software project.

How to reproduce:
1) Create a New Job name TEST.NEXT, choose "Build a free-style software project"
Add build step: Execute Windows batch command
echo EXECUTING TEST.NEXT
2) Create New Job name TEST.FAIL, choose "Build a free-style software project".
Add build step: Execute Windows batch command
cmd /C exit 1
Build other projects: TEST.NEXT, check "Trigger even if the build is unstable"
3) Start TEST.FAIL job, which fails. The TEST.NEXT job is never executed

Note, that I am not sure if the Jira core component is correct.


Originally reported by igorsmereka, imported from: "Trigger even if the build is unstable" does not work for free-style software project
  • status: Closed
  • priority: Major
  • resolution: Not A Defect
  • resolved: 2010-07-29T23:02:46+00:00
  • imported: 2022/01/10
timja commented 14 years ago

km:

Reproduces on Linux as well.

I am not sure why the configuration to trigger downstream project even if a project fails is provided. Anyone? It appears to me that if the build and/or post build actions fail, the downstream project should not be triggered at all. Comments?

timja commented 14 years ago

km:

Ok, some more insight gained after reading code. Hudson distinguishes between "unstable" and "failure" states of a project. A failure is more akin to build failure (e.g. batch file exiting with exit code 1) whereas an unstability is more akin to test failure. Since in this (trivial) example, the upstream project fails, the downstream project is not triggered. I don't know how to simulate an unstable build with a batch/shell script based free style project.

I agree however, that this configuration is somewhat confusing to users. If an upstream project contains (build + tests) combined and a downstream project cares only about the "build portion" of an upstream project (per sited use case), then maybe the upstream project should be divided into two distinct projects and then two projects rely on its success. (i.e. A -> B and allowing B's trigger even when A is unstable is not as clean as A -> B, C and then B and C are triggered only when A finishes successfully).

timja commented 14 years ago

mindless:

If the build fails (result is red), the downstream job will not trigger. That checkbox means to trigger even if the result is unstable (yellow).

If you need to trigger even for failed builds, try using the parameterized trigger plugin instead of the standard "trigger other jobs" option.

timja commented 14 years ago

igorsmereka:

I will look into the parametrized trigger plugin, however I am surprised such failure triggering is not a part of the stardard Hudson design.

Here is a "standard" situation when this functionality would be very helpful.

Suppose you build project A. If project A builds successfully, it copies its build source and binaries into "last good build location for project A".
Then you have project B that is dependent on project A.
However instead of building against the current A location which could have failed in the previous step, it builds instead against "last good build location for project A".
This way if project A fails, B could still be built successfully against earlier good version of A.
Which makes the whole build system much more robust.

Obviously, in such a system you would want any downstream project to be triggered even if any of the upstream projects fail.

In our company we build 30 projects having such dependencies on a CI server, which is an old customized version of CruiseControl.NET.
It takes a long time (more than half a day) to build all of the 30 projects, so the build runs once a day on schedule.
If we allowed the build to stop on the 1st upstream failure, then many downstream projects won't be build during that day, so the integration won't be even remotely "continuous" for those other projects.

timja commented 13 years ago

kay_abendroth:

Out-of-the-box Jenkins should provide a way to trigger even if the build failed also, if unstable and failing builds are not the same.

We use Freestyle-Projects to call shell scripts which act as wrapper-scripts for our tests. Failing tests should not prevent other tests from being executed. But without using a plugin that's not possible right now.