Hi guys,
I’m wondering if it’s possible to update a TFS repository half way through a build. Putting it simply, the first stage our of build configuration is a finalbuilder project which checks out some files, makes changes, and checks them in. Then directly afterwards, the build stage runs (using a continua visual studio action), followed by MSTest and deploy stages:
CHANGES > BUILD > TEST > DEPLOY
Between the changes and build stage, the repository needs to update so the changes made in the first stage are included in the build. Can this be done?
From what I understand the repository is only checked for changesets when I trigger the build, or at the polling frequency I set in the repo settings.
One idea I had was to set the frequency to 30 seconds, and then add a delay action of a minute or two to the build stage so that the repo is updated before the build. But would this work? Or would that still not update the source files used by the active build?
I understand I could probably do the changes stage in a seperate configuration, and then trigger the build configuration when that finishes. But i’d rather avoid that and have everything in the same configuration if it’s possible.
My fallback is to just use a finalbuilder project for the entire thing, but I want to make use of the unit testing features in Continua (or is there a way of displaying unit test results from a fb project in continua?)
Any advice on this would be great.
Many thanks,
Luke
Thinking about this further now - I can probably just pass the workspace created by Continua to the finalbuilder project that does the changes, and map TFS to that workspace for checking in/out changes, in place of using a seperate temp workspace. Then the updated files will always be there for the build stage? Correct me if i’m wrong!
Ok that idea didn’t seem to work. The finalbuilder project makes changes to files in the continua workspace (e.g. E:\Working\CIAgent\Ws\6052…), but these changes don’t appear in the build. I’m guessing the build stage somehow overwrites these changed files again from the repo before building.
Hi Luke,
You need to look at workspace rules. This will allow you to control what is copied between the agent and server workspaces.
For example:
Using the default repository rule in the Changes stage, “$Source$ > Source”, the repository TFSTest is checked out to $Workspace$/Source/TFSTest. You then have a FinalBuilder action which makes changes to files in $Workspace$/Source/TFSTest and commits them back to the TFS repository.
Use the workspace rules on the Changes stage to copy the changed files back to the server workspace ready for the Build stage.
/Source/TFSTest/ < /Source/TFSTest/Then add a workspace rule to the Build stage to copy the changed source files back
/Source/TFSTest/ > /Source/TFSTest/Note that you should also clear the repository rules from the Build stage to prevent Continua also copying the original source files to the agent at the start of the Build stage.
Hi Dave,
Apologies - never got back to you on this one. Went away on annual leave and just had a chance today to implement it. Works a treat! Updated files are now included in the build.
Many thanks,
Luke
Hi guys,
Sorry to revive this thread - having a bit of an issue with this workflow. I have a condition using $Build.HasNewChanges$ on my configuration, which should only trigger when new changesets in the repo are detected. However, because i’m making an automated changeset as part of the build itself, it’s building every night regardless of whether any of the developers make changes themselves, because it thinks this is a change we’ve made since the last build. Is there a way to exclude particular changesets from this check? (it’s the same files that are being changed each time)
Another question - i’ve noticed the version counter on the configuration still increments even when the build is disgarded, is there a way to stop this so it only increments if the build runs?
Regards,
Luke
Hi Luke,
We added a feature in version 1.7 to allow you to trigger on specific file change type and files matching a regular expression pattern. We also an option to decrement the version counter if a build is discarded… See more about these features in the blog post
You guys are full of solutions, nice one. I guess it’s update time p.s. love the new builds view