Setting build number pattern when none exists?

Sorry to post again so quick, but this is the last thing I have to do on this plugin before we deploy it. So what I am doing in part of the plugin is copying build configurations. Some of these build configurations do not already contain a build number pattern, and just use the default formatting {0}. When I copy these build configurations I would like to have the copies have the build number pattern "text {0}". So I am using this line of code to attempt this:

BuildConfigurations.get(i).getBuildNumber().setBuildNumberPattern( "text" );

It returns a file not found error when this line executes on a build that has no build conifguration currently. I think this is because the build number pattern just gets stored in a text file somewhere on the server, and it isn't created until the first time the build number pattern is created. So my question is how do I set the build number pattern without one already existing? Appreciate any help.



Can you provide the exception stacktrace?


I am sorry Pavel, you can delete this post. I just figured out what I was doing wrong when I attempted to get the stack trace for you. I was trying to obtain the build number pattern for a build config I had already copied. And since I am not calling persist yet because it is easier to test then it was not creating the build number pattern file. That is why it was throwing the file not found, not because of the prior project not having the build number pattern. I guess by default the actual build number pattern is {0} which exist no matter what. So again sorry to waste your time, and thanks again for being so helpful.



By the way do you use SProject::createBuildType(SBuildType, String, CopyOptions) method when you copy build configuration? If not you probably should, unless you are doing something unusual. This method will correctly map dependencies, process VCS roots, roles and so on.


Actually we are copying full projects, not just build configurations (I wrote that to make it easier to understand). The problem with just doing a project copy in the UI is that we want to change the names, build number patterns, and svn url's of all the build configurations within that project we are copying. So currently we do the project copy, and then manually go through and change each one of the build configuration names, build number patterns, and url's. This is a big time waster, so I thought I could write a plugin to do the same thing. So right now I am calling createProject(projectWeWantToCopy, oldName.concat("something"), buildOptions). Then I loop through this new project's buildConfigurations updating all of the information I need to such as their names, url, and build pattern number ect ect. But thanks for the info.



I just read through what I wrote and it didn't make much sense. So here is a better break down. If the project in the left column is what we currently have, the right column is what we want it too look like when we are done with the copy.

ProjectName ProjectName[release]
BuildConfig1 BuildConfig1[release]
   - buildNumber Pattern = {0}      -buildNumber Pattern = release-{0}
   - SVN Url = http://something/trunk     - SVN Url = http://something/branch/release
   - SVN Root Name - Sandbox     - SVN Root Name - Sanbox[release]

But we have hundreds of build Configurations and we are wanting to change those values for each one of them. So doing it manually seems stupid. Hope that explains better what we wanted to accomplish. The plugin is working now too, so it is effectively copying a project and changing these values.


Well, project can be copied with help of API too (see ProjectManager::createProject(SProject, String, CopyOptions) ). I only wanted to warn you about possible problems if you wrote your own copy propject procedure. If build configurations you are copying are not using dependencies and you do not need to copy notification rules and roles - such code will work, in other case it may copy build configurations incorrectly.

Consider the following case: you want to copy a project with two build configurations A & B, where A depends on B. If you just create A' & B' as raw copies of A & B then A' will depend on B, but it should depend on B'. Our API fixes such problems automatically. So if you are not using API, consider switching to it.


Please sign in to leave a comment.