This version adds several back-end performance enhancements including significant improvements to database query caching. We have also updated various third party packages and upgraded the bundled PostgreSQl database from version 9.3.4 to version 9.5.3. What’s more, this release builds upon all the improvements and fixes made to version 1.8.
New Actions
To keep up with the latest developments in Visual Studio, we have added several new actions for working with .Net Core projects. The DotNet Build, DotNet Pack, DotNet Publish, DotNet Restore, DotNet Run and DotNet Test actions all run the DotNet Cli command line.
This release also includes a new action for importing XUnit tests from an XML report file. The sort of file you may choose to output from the DotNet Test action.
To polish this off we have added new NPM Pack and NPM Publish actions for sharing your completed packages.
New Build Event Handlers
A powerful new addition to the Continua CI build event handlers is the HTTP Request handler which allows you to send JSON or XML to HTTP endpoints via GET, POST. PUT, DELETE, PATCH methods and extract values from the results to set as Continua CI variables.
This enables interaction with a various existing web services and REST APIs. You could, for example, use this feature to send a message via Slack when a build starts, tag a commit on GitLab when a build finishes or even translate a variable value to Azerbaijani using Google Translate API. If you have any in-house web services which handle HTTP requests, it is likely that these can be accessed too.
We have also added a new GitHub Release build event handler for creating, updating and deleting GitHub releases. This also allows you to upload artifacts as GitHub release assets.
Other New Features
Build Event Handler conditions. You can now control the triggering of handlers based on the value of build variables or expression objects. These values may be specified when queuing a manual build or set in the stage workflow. You could, for example, only send a GitHub Release if the number of failed unit tests $Build.Metrics.UnitTests.Failed$ is zero.
Continue on failure. Builds can now be set to progress to the next stage after one stage has failed. Stage gates now include an $Stage.IsSuccessful$ condition by default. This can be removed to allow the build to continue to the next stage when a stage fails. So you can see what failed, the stages are now coloured green or red in Tile and Details dashboard views to indicate an success or failure status.
New cleanup options. We have also made some changes to the server cleanup policy, giving you the options to clean up build statistics. The database category has also been split up so that build unit tests can be cleaned up without cleaning up the full build. This is important to prevent database tables growing too large when you have a large number of unit tests.
