Using a newly created Tag/Branch in checkout tasks at later stages in the plan

[Ivan Kozhirug]

I am trying to create a build plan which has a VCS Tagging(or VCS Branching) task in its first stage, and then at later stages uses the newly created tag(or branch) to checkout code from it(repository is SVN). I use a plan variable for the tag/branch name - ${bamboo.repoBranch} - and this variable is also used in the repository URL. I understand that this URL would not be valid until the tagging/branching task is executed, but tasks that try to checkout from that URL are at later stages. From what I understand, there is something like a code change detection phase, during which Bamboo checks all defined repositories for changes(no matter the order they are referenced in the plan or even if they are not used in the plan at all). I think this is the reason my approach doesn't work, is that correct? Here is the exception I get:

com.atlassian.bamboo.repository.InvalidRepositoryException: svn:

at com.atlassian.bamboo.repository.svn.SvnRepository.detectCommitsForUrl(SvnRepository.java:527)

at com.atlassian.bamboo.repository.svn.SvnRepository.collectChangesSinceLastBuild(SvnRepository.java:278)

Another alternative to what I am trying to achieve is to have a plan that creates a tag/branch and a child plan of that plan which uses the newly created tag/branch. The problem with this is that plan variables cannot be passed to child plans - I want to use Run Customized to override the value for ${bamboo.repoBranch} and the overriden value to be passed to the child plan. From what I've read the workaround for this is to use a script task which using the Bamboo REST API queues the next plan for execution, but this seems a not very elegant solution.

Any other approaches for what I am trying to achieve will be helpful.

Thanks

[Przemek Bruski · Accepted solution]

You could try switching to that branch/tag using a Script Task.

You can't use Bamboo repsoitories for that because they operate on repository state as it was at the point the build was triggered.

[Kevin James]

a bit confused by your comment Przemek. You say that it depends on the repo state when the build was triggered but what is the point of the VCS tagging task then? Doesn't tagging infact represent a state of the repository, I mean, that is what tagging is right - marking all the revisions. So, one should be able to use *this* state from the tagging task.

In addition, even if I use the source code checkout task, isn't that the point at which the repo state matters? If the build is triggered and 20 mins later my source code checkout task executes then why would the state of the repo at trigger time matter?

[Kevin James]

This seems like a limitation. If there is a built in task to create a new tag then it should be available for later tasks. I have parameterized my repo location but I get the exact same error Ivan gets: "repository does not exist". It seems to be validating the repositories before the tasks even start so the tag has not been created yet.