Upgrade Procedures
Important Changes Affecting 1.x, 2.x and 3.x Users
- The queue concept in previous versions has a major drawback that it does not tie with agents, therefore, it is hard to tune concurrent builds based on available agents. Therefore we replaced queue with resource which can be configured to play the role of queue and can be more powerful. However since queue and resource are different concepts, we can not migrate previous queue settings. Users migrated from previous versions will see that the grid allows all builds to happen immediately without queuing. Refer to Resource Management on how to queue your builds by configuring appropriate resources.
- Changes for builds generated by QuickBuild 2.x will not be displayed, as we changed the storage mechanism in 4.x to disclose more commit information, and this mechanism is not compatible with the one used in 2.x. Changes information for builds generated by QuickBuild 3.x can still be displayed.
- Existing test history of TestNG will be dropped. The reason is that previously we used method name as key, which is not accurate due to method overloads. In 4.0.x, we use method signature instead to avoid this issue and unfortunately this is not compatible with test history generated by previous versions.
- Changes detection is now happens on the node running master step in order to reduce server load. So please make sure that relevant SCM tools are installed on the master node if necessary.
- The step pre/post action Cancel sibling steps if current is failed has been removed. To fail other steps if one step fails, please edit the parallel composition step, and check the Cancel On Error option.
- The notation to reference latest build with a configuration id has been changed from <configuration id>:latest to <configuration id>.latest, and the same applies for latest successful/finished/failed builds. Refer to build name for details.
- If you have custom plugins, make sure to export all packages of the plugin, and then rebuild and redeploy your plugins.