I am trying to make a build process that increments the build version by 1 in my AssemblyInfo and then pushing that change back to the remote repository.
However this is not possible, because git does not recognize the workspaces directory for source files ($Source.MyProject$) as a git repository as it does not contain the “.git” directory.
Is it just me, or am I missing something essential here?
Is there anything that I can do to make Continua put the .git folder alongside the source files as well?
Or am I forced to clone the repository again in another location?
Hi Fredrik
Continua CI creates a clean build workspace folder with the source (and other files you specify) for each build, the repository itself is not available in the build workspace. We only support server side checkout, which is then maintained in our repository cache (an hg repo) which is synced to the agent for use during builds. Currently the only push we support is from the server to the repo for tags. We do have plans to look into committing changes during a build but cannot say at this time when we will get to it.
BTW, is there a reason you need the assembly version committed to the repository? We used to do this long ago, but since we never released builds from anywhere but our build server the actual assembly info in the repository doesn’t matter, since we set it during the build process.
Hello Vincent,
thank you for answering so fast. About your question:
I can see how letting Continua update, but not commit, the AssemblyInfo works in a simple repository with a single branch. But how would you solve the problem where you have a development branch and a release branch (like in git-flow)? Whenever we are in a release phase, we still want nightly builds on the development branch as well as the possibility to build release candidates or a release on the release branch. During such a phase, these branches have different versions with two different build version counters.
Also, how does continua handle building tags in this case, where tag creation is completely handled by git-flow? What happens to the AssemblyVersion then?
To me, handling the versioning within the repository and having Continua parse (like you can in FinalBuilder), update and commit the AssemblyInfo back into the repository makes these problems easily solvable. It also provides transparancy, where the version can be found in Continua as well as in the repository.
Regards,
Fredrik Pettersson
Hi Fredrik,
Sorry for the delay responding to your second question.
Another user has written a blog post about using GitVersion with Continua CI to generate the version number. The generated variable can then be used to update the AssemblyInfo file for each build.
If the number is generated every time you build, there should be no need to commit the AssemblyInfo file back to the repository We do, however, plan to provide a method for committing build artifacts to the Git repositories (and some other repository types) in the future.
You can currently commit and push a Tag to the branch of the repository being built using a build event handler. The tag name can include build variables such as the version number generated by GitVersion.