Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,467,278
Community Members
 
Community Events
177
Community Groups

Writing plugin: How to continue to next stage should failure occur

The idea is that should a job w/in a stage fail we would like to continue execution to the next stage. The approach I'm taking is to mark the particular stage as having passed, should a failure occur, and continue execution (as I can't find any other way to continue execution whilst a job is marked failed). Once all execution has finished I can go back and mark the jobs which exactly did fail as having done so. So here's my questions:

1.) Is this the correct approach to take?

2.) Assuming yes to #1 where can I make this happen? I see no documentation on how to mark a Stage as having passed. Does it pull in results from all executed jobs? Why cant I mark/update the Stage status as having passed like we can w/ buildresults and chainresults?

5 answers

1 accepted

1 vote
Answer accepted

I think a different approach may be easier. Instead of modifying the Stage and Jobs results, try altering the task result using com.atlassian.bamboo.task.TaskResultProcessor . Have a look at com.atlassian.bamboo.task.QuarantineTaskResultProcessor for examples.

The final task would be to make the information about test failure somehow visible - maybe extending the Quarantine functionality to automatically quarantine tests would be enough?

But that simply does not make sense. Doing the above I would have to write a custom tasktype right? But w/ that aside why expose methods in the sdk to update the lifecycle and buildstate if they are not going to be honored anyway?

You wouldn't need to create a task type - but forget about it, I've noticed that the TaskProcessor is not pluggable.

Yes, the stage result is inferred from states of all builds in a stage.

Try the following - implement a PostStageAction. The action will get StageExecution object.

StageExecution has a private stageState variable, get it through reflections and execute getBuilds() on it. You should be able to change the build status using markAsFinalized. This should let you fool Bamboo into running a Stage that failed.

Maybe there's a simpler way of doing that, but I was not able to find it when I looked briefly at the code. It does look hackish but that's because Bamboo was not supposed to continue execution of Plans with failed stages/jobs. The correct way is to make sure the indidivual builds in the Stage end with a successful result - unfortunately, since the TaskResultProcessor is not pluggable, you won't be able to do that without modifying Bamboo's current TaskResultProcessor.

Speaking of which, my suggestion would be to modify Bamboo's code directly (i.e. change the TaskResultProcessor). It looks like a cleaner solution and we will probably make the TRP pluggable at some point, so you'll be able to migrate your code to a plugin.

Oh, and creating your own task type (by extending one of the existing ones) is also an option.

Awesome! With a bit of playing around I was able to "fool" bamboo into thinking the stage passed though there were obvious failures. Thanks for pointing me in the right direction.

Have someone found a way how to configure a behaviour discussed above?

In few words: do not stop/fail entire build after one stage failed. Just go to further stages or smth like Final Tasks in jobs (but Final Stages).

I can explain why: we have a custom script, that checks some information after all stages finished. So, instead of putting it on every Stage, that would be convenient to have it in such Final Stage. Especially, if this script should gather information from all of the Stages.

0 votes

Yes I did! Given Przemek's advice I was able to use reflection to get the job done. Basically we set a config option on each job that if it fails to continue execution to next stage. If it does fail reset status (via reflection) to pass. This has the side-effect of having all Jobs being marked passed while execution is happening but we thought that acceptable. Once chain finishes we go back and re-mark all those jobs which failed, but were marked as passed, back to fail.

I know its been a while but I'm wondering if you did this by implementing a PostStageAction per Przemek's advice? If so is there a public repo where I could grab this or would you be willing to share it? This would be extremely useful for us too, right now we are just forcing builds to continue manually by disabling the failed jobs and choosing 're-run failed jobs' and then re-enabling the failed jobs after the build. It would be great if we didn't have to do all these manual steps. Thanks!

0 votes

Absolutely! We have test "suites" which to us are a string of tests (by tests I mean stand-alone scripts written in ANT. Some of which do actual testing and some of which do not.) which need to be executed sequentially. We have broken down each of the "tests" in this suite into its own stage. There are times that a "test" fails but we do not consider it a "stop the world" failure. We want the failure to be shown (i.e. the stage as having failed) but we'd also like to continue execution of the remaining stages to see how they fare.

0 votes

Hey Christopher,

could you tell us something about the use case behind this?

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events