This version adds several new features which build upon all the improvements and fixes made to version 1.7.1.
We've added a new filter box to the dashboard so you can quickly find the configuration (or project) that you are looking for as you type. Use the shortcut key F on the dashboard pages to focus on the filter box and start typing.
Many of you have requested more control over the number of builds which can run concurrently for some configurations. This may be to restrict the number of times a particular tool is run due to a license, memory or processor limit, or to prevent concurrency issues with multiple build stages simultaneously writing to the same file, folder or network resource.
You can now allocate quotas to named Shared Resources and specify that builds and stages must acquire a lock on the Shared Resource before running. If all locks are allocated, then the build or stage will wait on the queue until a lock is released.
Shared resources can be associated with the server or a particular agent in the Administration pages.
Agent shared resources are acquired when selecting an agent to run a stage. Continua will select the agent with the largest available quota of each shared resource.
Server shared resources can also be acquired when selecting an agent, or while on the build queue after evaluating configuration conditions.
We hope you find that shared resources can provide many different ways to control the build process.
Sometimes a build may fail due to an offline network resource, or some logical error in the stage workflow. Up until now, your only option was to re-run a build for the same branch heads. If any new changesets had been committed to the branch since that build, then you are out of luck.
The new Requeue Build button on the Build View page allows you to requeue an existing build using the same changesets, variables and queue options. Any changes to the configuration such as stage actions or repositories are taken into account and used for the new build.
You can also change the priority, comment and variables before requeuing the build.
Clicking on the “Build requeue options” menu item will open the Queue Options dialog.
Persist Build Variables
Another common request has been to persist variable values from one build to another build. This may be to keep a count of builds on a particular branch or to flag that some actions have been completed in one build and do not need to be repeated.
Continua CI takes a copy of configuration and project variables at the start of each build. These copies are referred to as build variables. Any changes to build variables are normally discarded when the build finishes and cannot be used by other builds.
The new Persist Build Variable build event handler allows you to save the value of the build variables when specific events happen in the build timeline. This is stored as the value of the configuration variable. Subsequent builds will then pick up this revised value and use it as the initial value of the build variable.
As Continua CI allows multiple builds to run concurrently, it is important to control when the variables are overwritten. A later build may run faster and finish before a build which started earlier, causing unexpected results. You can optionally state that a variable should not be persisted if the configuration variable has been modified (e.g. by another build) since a specified build event, such the build start.
You can also prevent concurrency issues by using this feature in conjunction with shared resource locks.
Other New Features
- You can now set the Variables display order of variable prompts on the Queue Options dialog.
- We have provided buttons for cloning Triggers, Repositories and Build Event Handlers.
- Configuration Conditions can now be disabled.
- We have also added a new Cake build runner action