Hi
We are trying to configure Continua so any unstarted but queued builds are discarded when a build is triggered because of new changes.
We though that the $Build.HasNewChanges$ could be used, but it seems to discard all our builds.
Hope you can help.
Thank you,
Thomas
Hi Thomas
There’s no way to discard already queued builds (other than manually cancelling them). I’m not sure it would be feasable to implement such a feature, but I’ll add it to the todo list to investigate.
Perhaps a better solution would be to make use of the Quiet Period on the Trigger. When the build is queued, it will wait until the quiet period expires before starting the build. During the quiet period, any new changes that are found are added to the already queued build and the quiet period is restarted.
Posted By Vincent Parrett on 16 Sep 2013 02:26 AM
Hi Thomas
There's no way to discard already queued builds (other than manually cancelling them). I'm not sure it would be feasable to implement such a feature, but I'll add it to the todo list to investigate.
Perhaps a better solution would be to make use of the Quiet Period on the Trigger. When the build is queued, it will wait until the quiet period expires before starting the build. During the quiet period, any new changes that are found are added to the already queued build and the quiet period is restarted.
Hi Vincent
From our point we get a build queued for every checkin, this is fine but if the next 2 checkin's are to the same solution while it is still building the first checkin or busy building other solutions. We dont want it to build both of the checkins only the last.
So we do not want it to wait before it queues the first build, there is no reason for this, we do not know if the next checkin will be in 1 or 10 min. But it makes alot sense (from our perspective) to discard any checkin triggered queued builds on the same solution. We quickly have a queue with many instances of the same solution.
Really what we are after is an option to only have one instance of each solution in the queue at a time. Sort of a "if (solution in queue) then DONT add to queue else add to queue" behavior so we only requeue solutions if they are not about to be build.
Does this make more sense for you? And thank you for your fast reply.
Thanks, Thomas
We're not entirely clear on this, but our understanding that you want to allow a build to stay queued while a previous build is running for the same configuration.
Any new changesets received for the same configuration should be added to this queued build while the previous build is running. Once the previous build finishes, the queued build would run, building the latest changeset at that time.
This is similar to a quiet period which lasts as long as the previous build runs. The option would be something like "Stay quiet while another build is running".
Are we describing the same process?
Hi Dave
Yes, that is the behavior we are after.
Best regards, Thomas
+1. It’s amazing how many times I submit a change set then start working on the next bug or nunit failure and find a quick fix in <5 minutes. I would love continua to discard any interim builds that are in the queue if new changes come in. This is particularly important for integration testing nunit runs that can take considerable time to complete.
The behavior that Dave described is something we will look at adding. At this time I have no idea if it’s a simple task or not, or in what timeframe it will be done (depends very much on complexity and other task priorities). It has been written up in our system as a feature request.
Happy to hear you have included this in your backlog.
The solution Dave describes are fine, but I think it could also be solved using your discard conditions if we had some more options, as Jamie is describing. If this is simpler and fits your current flows better.
Looking forward to get that feature… and thank you for a nice product.
Discard conditions only operate on the build currently being queued, they won’t allow you to kill a build that’s already queued/running. I did look at the object model for the discard conditions, but it’s not a simple thing to provide it with access to the number of running builds for that configuration, as repository branches also need to be taken into account (a build running with a commit in branch A is not treated the same as a build running in branch B).
I agree we need to implement something like what has been requested/described, but it will need some careful thought and research to implement something that fits the needs and doesn’t cause other problems.
Great, glad to hear. Looking forward to see what you come up with.
+1 on this feature for a queued build to accumulate changes instead of having several individual queued builds. My build runs for 30 mins and I don’t want to set a quiet period of that time if there is an available spot to run the build.