Prevent failed builds from "consuming" JIRA issues? #1622

Zac · 1 decade ago

Good morning,

I was wondering if there's a way to configure QuickBuild (4.0.5) so that when a build fails, it doesn't "consume" the JIRA issues & SVN changes that were present when it started. Currently, if I run a build that fails, its SCM Changes and JIRA tabs show the issues that were present when that build was triggered. If I then run another build that succeeds, that build doesn't include the issues from the failed build prior to it. If I delete the failed build before running the new one, then it does gather up all the issues & changes including those present when the failed build started.

We'd like to know when fixes & changes first appeared in an actual build, and we wouldn't consider a failed build as the "appearance" of those changes as it never saw the light of day.

Thanks,
Zac

replies 5
views 2915
stars 0

steveluo ADMIN · 1 decade ago

Hi Zac,

Do you mean you just want to display issues in a successful build or both changes and issues? Currently, there is no way to delay "consuming" the issues to later successful build. Please file an issue to our tracker below:
http://track.pmease.com

drdt · 1 decade ago

Is the list dynamic? Meaning, can you just delete the failed builds and have the changes then appear magically in the next build?
Or do you have to delete the failed build before starting the successful one?

Zac · 1 decade ago

The list appears fixed once the build begins. Only deleting the failure prior to starting the new build has any effect.

Opened: http://track.pmease.com/browse/QB-1117

Thanks,
Zac

steveluo ADMIN · 1 decade ago

Hi Zac,

After reading the issue QB-1117 you submitted, I think I know what your mean now. But I think it may needn't delay 'consuming' the changes and issues because you can compare with previous successful build or even with any specified build from the tab, and this will keep the changes and issues more accurate.

For example, build 1 was successful, and in build 2, you made some changes and fixed TST-1, TST-2 and TST-3, also some changes were made to try to fix TST-4 but those changes caused build 2 failed, and in build 3, you committed again to fix TST-4 successfully, in your case, you want to see all issues TST-1 to TST-4 in build 3, but I don't think to repeat them in both build 2 and build 3 is a good idea, because TST-1 to TST-3 was actually fixed in build 2, although the build is failed. Instead, you can compare with build 1 to show all changes you made and all issues fixed.

How do you think?

drdt · 1 decade ago

I have recently joined a new team, and they have the following solution to this problem (albiet they are using Jenkins, but I am working to bring them around).

- have a 'continuous' build that runs every time there is a check-in, but doesn't post any artifacts. if the CI build succeeds, drop down a 'PASSED' label
- have an 'official' build that runs every two hours (or whatever), and posts artifacts, but only if the 'PASSED' label has moved.

This way, each official build will list all of the changes since the last successful build, because the failures will be consumed by the CI build.