Bamboo - How to lock and increment version number?
Asked by Summer X:

Hi,

I'm using SVN and bamboo. All of our stuff in in trunk, and my problem is two-fold.

1) I need to check out a file in the repository (version.h) and increment it, then check it back in, before I can do a build. I'd really like this to be part of the build because I just might forget

2) I need to tag the SVN repository to an official release number (NOT the same as bamboo build number OR SVN revision#)once the build is finished. But I'm afraid other people might check-in things into trunk while the build is going on, so I will end up tagging a different revision than what was built.

So my plan to tackle these two problems so far is:

Have the pre-build command in Bamboo run a shell script. It checks out the code to a temp folder, increment the vesion.h, then tag it with the name "LATEST" (this name is not going to change). Then have Bamboo set up to always check out TAG\\LATEST instead of trunk. Then, set up the post-build command to run another shell script so it copies the LATEST tag to a tag with the official release number as its name

But this solution seems rather inefficient. Can you please give me some pointers? I'm very new at this...

Thank you everyone!


Answers:
author: Przemek Bruski
body: I think you should add a task that modifies the version.h, tags the workspace content with tag name being bamboo build number (and whatever else needed to make the tag unique). Something like

insert_version_h_modifying_magic_here

svn cp . URL/tag-${bamboo.buildNumber}

If the build succeeds, do

svn mv URL/tag-${bamboo.buildNumber} URL/release_tag

If it does not, do

svn rm URL/tag-${bamboo.buildNumber}

In either case, run

svn revert -R .

As the finalising task.

comments: author: Summer X
body: Thank you for your answer. Can you please elaborate? So I need to have bunch of tasks:

1st: Checkout source codefrom trunk

2st: Use a script to increment the local copy of version.h

3rd\&4th: Check in the updated version.h and check it out again?? Because otherwise the repository will not have the new version.h, so in step 5 I will end up tagging a revision with the old version.h, right?

5th: Use svn cp to tag the repository with a unique name

6th: If successful, change the tag name to my release name, otherwise remove tag

So I'm still not sure about step 3 and 4, and also, why do I need to revert the repository? I do want the version.h incremented..

One more thing.. So Bamboo does not have the option lock the repository while building? I would imamgine it'd be a common practice to build then tag the repository, so it is important to not let people check in anything while a build is going on, otherwise you will tag stuff other than what was built. How do people usually get around this?

Thanks again!


author: Przemek Bruski
body: > 1st: Checkout source codefrom trunk

Let Bamboo do it.
> 2st: Use a script to increment the local copy of version.h

Right.
> 3rd\&4th: Check in the updated version.h and check it out again?? Because otherwise the repository will not have the new version.h, so in step 5 I will end up tagging a revision with the old version.h, right?

The lines I've given will already tag the new version in the repository.
> 5th: Use svn cp to tag the repository with a unique name
>
> 6th: If successful, change the tag name to my release name, otherwise remove tag
>
> So I'm still not sure about step 3 and 4, and also, why do I need to revert the repository? I do want the version.h incremented..

Not the repository, you revert the working copy. It should not have any local modifications.
> One more thing.. So Bamboo does not have the option lock the repository while building? I would imamgine it'd be a common practice to build then tag the repository, so it is important to not let people check in anything while a build is going on, otherwise you will tag stuff other than what was built. How do people usually get around this?

Just build a tag, not the branch/trunk. Locking the whole repository is bad design. You can do it with SVN with hooks, but it's a bad idea.