This release updates the plugin to be compatible with the new version of Bamboo (5.0). There are also some bug fixes in this release as detailed below.
This release updates the plugin to be compatible with the new version of Bamboo. There are also some bug fixes in this release as detailed below.
This release updates the plugin to be compatable with the new version of Bamboo, no new code needs changing however there are some obvious pom file changes and some wiki documents for the development of the plugin.
The changes included in this release means that you will require an additional jar included in the same directory that the plugin resides in. This jar is included for performance analysis currently included in the plugin code which you can, if you like make use of. This was included to drive out some changes such as only checking the stream hierarchy periodically because of a threading issue with large instances.
What it really means for the plugin is that it checks often for changes that occur from promotes but doesn't check changes flowing down from streams above the one that you're polling on.
The new jar is included in the download section, you will need to also configure log4j settings and the development options means that you can set this where appropriate.
This was a relatively small change, the internal abstract repository class that the plugin class extends has changed therefore required a change. This means it does not work with previous versions of Bamboo. There are a number of small changes also put into this release, as detailed below.
This was quite a large change in that now the plugin is using a diff on the stream instead of a hist of the stream and every stream in the hierarchy. This should greatly improve performance of the plugin, both for not kicking off builds which are not necessary and also not storing huge amounts of data on commits. The plugin will look at the first 10 files which have changed in the stream and complete hist's on it to get the details. I limited this as there could be hundreds of files in a promote.
|#4||Use diff instead of hist|
|#13||Problem with line separators|
|#3||Pass the error from accurev back up to the RepositoryException so that the error can be seen by the user in the build log|
|#5||Bug fix to clear the sub directory path when the check box is deselected|
|#6||Expose accurev variables (like stream) to other tasks|
|#7||Move comparability to 3.2 Bamboo version|
|N/A||HashCode and Equals||The AccurevRepository doesn't not override the hashcode and equals methods, added this|
|Builds not being triggered post 1.4.3 release||We have noticed that some plans were n olonger triggered for changes that were not included in any of the folders included in the targeted Stream. This was due to the fact that the plugin was considering a blank "subfolder path" field instead of ignoring it: bug fixed.|
|N/A||Excessive builds being completed post 1.4.0 release||After the changes completed by release 1.4.0 in order to remove the need for the stat command (which was causing garbage collection issues) there is a problem now that there are excessive builds being kicked off. There should be a way of comparing the versions of the files in the stream with the backing stream without an expensive stat command.|
|N/A||Remove the server login from the page||Since the server itself is logged into accurev it is unnecessary to specify the server that accurev does the checkout from. If a build is running on a sever which is located close to a slave server of accurev it should choose it instead of taking a configured plan.|
|N/A||Remove the logging of transaction types||There is currently logging in to see the types of transactions that are kicking off a build. This should be removed as it's causing excessive logging.|
|N/A||Excessive builds being triggered post 1.4.2 release||We have noticed that some plans were triggered for changes that were not included in any of the folders included in the targeted Stream. This was due to the fact that the plugin was ignoring elements only if they where part of an excluded folders. The problem with this is that only the explicit "excl" rules are available when executing an "accurev lsrules -s". Most of our stream are defined with "incl" rules and therefore the plugin needed changed so that the logic is now: "Only changes that are within an included folder of my CI stream are actually relevant".|
|Change to exclude builds on folders which are excluded||In order to cut down the number of builds which the bamboo plugin kicks off you can look at the transaction in the stream hierarchy but before you kick off a build you should check the include rules with a lsrules or a diff command which will tell you whether the folder is excluded in the CI stream which means that you don't want to kick off the build|
|N/A||Accurev Stat Problem||When the plug-in wants to check whether or not it needs to run a build it completes a stat on the stream that it is polling against. For large streams this stat (once for every time it checks the stream) has been seen to be up to and over 25Mb. Taking many streams this causes the bamboo server to fall over with out of memory errors. The way to mitigate this is to increase the available memory that bamboo starts up with and limit the stream that CI is polling off so that the stat is small. However there is still an underlying issue around the stat, is this the way that it should be checking for changes? This could be limited also by only checking the sub directory path that if it is filled in.|
|N/A||Kick off build on only files which have been touched in a particular set of files not whole stream||Since release 1.2.0 you can specify a sub directory to the top level of the stream which the plug-in will only check out from the root of your stream (see here for more). However the build will still kick off on any change to the stream that you specify, therefore we need the functionality to just kick off the build on the changes made to the files we're interested in|
|N/A||Previous parameter to collectChangesSinceLastBuild could be null||This was a change to the annotation to the method collectChangesSinceLastBuild as it had an @notnull on the previous parameter but it could actually be null, the check was then completed in the code of the method for the null value.|
|N/A||Security problem with login||This issue occurs because of the fact that the accurev plug-in does the login from the command line||This was fixed by removing the user login from the plugin itself. The login is then persisted on the actual server which runs the bamboo instance. Since the plug-in already uses the client to perform tasks if the user is logged into accurev with the following command|
accurev login -n <username> then the plug-in will be able to communicate with the accurev server
|N/A||Incompatibility with bamboo version 2.6||The plug-in needed updating to the latest version of bamboo.||The change included allowing the "previous" data which is passed into the collectchanges method to be null. This happens on a fresh install of the bamboo server where there is no previous data available. There are also subsequent changes where the previous data file was being looked for.|
|Be able to specify a sub directory path||Currently you specify a stream in the configuration page which means that the plug-in populates the whole directory tree in order to build the your pom. In the same way where you specify a directory that contains your pom when building with maven you can also now specify a path where you just want the code to be checked out. The user guide pages here explains how it works|