We are evaluating Continua CI for a while, and we found a strange behavior. Sometimes the builds are executed in a mixed up sequence.
E.g. the #129 build executed before the #128 build. Is it normal?
I assuming this is a bug in Continua CI.
[Continua CI Version: 1.0.0.2941]
Attachment unavailable
This is something that was fixed in the most recent update.
Actually the fix that we put in the last update was related to the order builds run after waiting on time-based conditions and you stated that you have the latest build anyway.
The default configuration version format ‘1.0.0.$Build.BuildNumber$’ is based on the build number which is allocated as soon as the build is created. The Recently Completed Builds are ordered by the finished time. Before the first build stage is sent to an agent, there is an initialisation period while the repositories are checked and the respository cache is updated as necessary. This is to ensure that we always have the latest source files to build.
The duration of this Build Initialising period can vary depending on a number of factors such whether the repository cache is already up-to-date, the number of files in current changeset and CPU/Disk usage on the server. Also if you only have one concurrent build license, the build which finishes the Build Initialising period first will be started first and any other builds currently initialising will need to wait for the license.
You haven’t provided any information on how these builds are triggered and why they are starting at close time intervals. If they are triggered by a repository trigger then it may help to set a quiet period so that changesets which are committed close together are accumulated before the build is started.
Thank You for the answer!
Some more info:
I am using the default configuration version format: '1.0.0.$Build.BuildNumber$'.
I am testing the free version of Continua CI (only one local agent, one concurrent build)
At the agent settings, I used the default (which is 2) concurrent stages value.
The configuration in question has two repositories (lets name it 'A' and 'B' repository), and both of them triggers a build.
I set up both repository triggers with only 1 min quiet period (because this is the minimum accepted value, and I wanted to start builds as soon as possible).
Both repository has normal polling frequency (60 seconds).
At first I committed into the 'A' repository, which is triggered the #128 build.
Then 137 seconds later I committed into the 'B' repository, which triggered the #129 build.
And somehow #128 build started later and finished later than the #129 build.
Based on You description and my further investigation, I think, Continua CI works as expected.
It is the nature of the distributed build architecture.
I think, this concept works well if we want to access to the build artifacts through the Continua CI. We can easily find the most recent build (which has the highest build number) on recently completed builds list.
But: we do not plan to use Continua CI's artifact registration option. Because we would like to use the Continua CI to automatically deploy (simple file copy) a build artifact into a dedicated folder (which is our developer environment). And we would like to reach the latest state of the program in that folder.
So, it is maybe a new whish from us: we would like a switch (assigned to a configuration) which forces sequential execution of the builds (which is valid within that configuration of course).
Or maybe it would be better to assign that switch to the stages. And we can switch it on in case of a deploy stage. In that case, the execution of the build stages can remains parallel.
The proposed workaround did not help. Just look at the picture below.
I incremented the quiet period time to 3 minutes. Then I committed into repository 'A' which triggered a #154 build.
Few seconds after I committed into repository 'B' which triggered a new build (#155) instead of accumulating the changeset into the #154 build.
[Continua CI Version: 1.0.0.2941]
Thanks!
Janos
Attachment unavailable
Hi Janos,
Quiet period builds only accumulate changesets started on the same trigger, so yes this will not be helpful in this case where you have more than one trigger. Note that you can set the quiet period to zero to initialise the build immediately.
Can you provide some information about the type and size of the repositories Trunk_Test and Trunk_Source? Also the size of the changes you are committing when you see this issue and details of the options set for each of the triggers? We are trying to replicate your situation here to see if there are any modifications we can make to the build initialisation phase to make it more consistant between builds.