I have multiple repos for different versions of my build - for instance, release, development, and experimental - this was decided on after a long decision process when moving from StarTeam (branch based) to Mercurial with the distributed model. These are actually different repos in Mercurial that get merged to and from when I promote changes to specific releases. To complicate matters, I have dependent code (framework, shared) which is also versioned into the multiple repos. For example:
project\x
framework\x
shared\x
project\dev
framework\dev
shared\dev
I’ve definitely been happy with the multi-repo setup to manage different lines of dev, but I am finding it hard to implement it in Continua. In FB Server, I had a single “master” FB project that would conditionally pull whatever repo I wanted to work on through a variable - so I could say “dev” and it would loop through my repos and pull all the ones with a /dev, if x, then /x and so on. I could essentially switch repos on-the-fly with little effort.
With Continua, since I have to define the repos upfront, my problem is that I seem to need to create 3 different configs that will essentially do the same thing - the only difference between the configs is the repo I am pulling from. Is there anyway to get this into a single config that you can think of? I just really don’t want to maintain three sets of stages, vars, etc when the only difference is the source repo. Can I add them ALL and put them in different folders (like Worskpace\dev and Workspace\x) then set variables based on which triggered the build? I think that would work, but wondered if there was something more elegant that I might be missing.
Hopefully that is clear - please let me know if you have any ideas for this. Thanks!
Ryan
Hi Ryan,
From our point of view, your best option would be to set up instance, release, development etc. as different branches of the same Mercurial repository and use a git-flow or (hgflow) branching model. This is how we work with our Mercurial repositories, but that’s probably not the answer you are looking for.
There are a couple of ideas that we have for future that would help in your scenario. One is configuration templates, where each configuration would be based on a template that could be changed in one place. This is just an idea so far and quite far off implementation.
We have also thought about allowing variables in repository fields. The issue with this is that we would have to generate different repository caches for copying to the agent each time the variable value changes. There is quite a lot of work to do to support this across repository types.
There is however currently a way to do this using variables in the repository rules. Set up a drop-down list variable e.g. RepoName with option values for each repository name e.g. release, development. Change the repository rules in the Stage Options dialog to:
%RepoName% > SourceYou can now choose which repository to export to the workspace, when starting the build manually.
Set up a Repository Trigger for repository - in the Variables tab set the RepoName variable to the name of the associated repository. This will ensure that the correct repository is exported to the workspace when a build is triggered by a changeset.
You can also add variables, rules and triggers for your dependant repositories.
Note that you need to associate all the repositories with the one configuration for this to work
Hmm. Ok that definitely gives me somethings to think about. I did think about making all the repos available, but didn’t connect that the repo rules would help me out there. I also completely understand why I can’t do variables in the repos because of caching and definitely wouldn’t think that would be viable - I really like the your design on that part, so wouldn’t want that to change.
I have no experience with Hgflow, so thanks for the link. I’ll look at it - one more thing to try and wrap my head around when it comes to versioning! It took me quite awhile to convert from the central to distributed (but of course loved DVCS once I actually got some working models going).
The only other issue I see is in build events when it comes to tagging - from a cursory look, it doesn’t look like it has generic conditions. So, if I do use a variable method and have all repos available, I can’t find a way to conditionalize which repo would get the tag. I know it is a new feature, and that I could also do it FinalBuilder, but I’d like all the repo logic contained in Continua. Are there plans to add conditions like in stages and triggers to the build events?
Thanks again for the detailed answer!
Ryan
Hi Ryan,
The original plan for build event handlers included conditions however we skipped that part to get the feature out quicker. It’s still on the to-do list - I’ll bump up the priority.
Awesome - thanks!