How to avoid creating new workspaces for each build and create only one root workspace for all builds?
We work with TFS. We have a big project with more than 30 components inside it and three branches of Development, QA and Production.
Each component increments Assembly version and checks-in on TFS on each build. Each component in TFS has to be mapped to the local folder separately by creating their own workspaces. At the end, we have 30 workspaces on each version which is a lot. How can we avoid this?
Moreover, the first build of any component always fails as the local folders are not mapped and assembly cannot be checked in. In the second try, it will succeed. The problem is when we release a version, one project with 30 components moves from QA to Production. And in order to make the moved project work in Production branch, we need to build all components once and let them fail, so they are mapped. This is also extra work and time.
Can we create just one workspace and map it with the root of TFS projects and then refer to this workspace for all builds?
Please sign in to leave a comment.
Hi,
How have you set up the access to the VCS Roots? TeamCity should pick up automatically the changes from the VCS Roots, and if you need specific folders to go somewhere else, you can use VCS Checkout rules for that, so teamcity should handle it all automatically. I'm not really sure why you need to perform local mapping, although I'm not too familiar with TFS so I might be missing something.
If you need to do the local mapping just to increment the Assembly version and make the check-in, it might make sense to set up an initial build that will perform that task, and then move the trigger to that build, and set up the other builds to trigger via finish build triggers, so that they can pick up on the already changed revision. It could also be done with triggers for the regular builds excluding the assembly version file and the trigger for the "version and commit" build just watching that file.
About the build failing the first time, that looks like an issue with your setup. If you know you need to perform the mapping, the best approach would be to include a first step in your builds that checks that the mapping is done and performs it if it isn't already in place. That way you wouldn't need to perform any manual tasks and builds should work on the first run. Again, I don't really understand the need for such mapping, so feel free to expand on that.
If this doesn't address your issue, please comment about what I'm missing.
Hello,
Thank you for the response. I think, VCS roots are correctly set up. Yes, TeamCity automatically picks up the latest changes with the trigger. But, let me explain the process behind it. Let's say the build is running for the first time. First of all, TeamCity should get the files from TFS into its own folder in somewhere like "C:\BuildAgent\work". In order to get the files, the VCS root for the build should be mapped with local folder (this will happen on TFS side - you cannot get files from TFS without mapping the VCS root with the local folder). In this process, TeamCity creates a workspace on TFS side. The image shows the build log in this process.
The problem is for each build, TeamCity is creating a workspace like this "TeamCity-A2-7a41a6aaef05433bab3ef7acc4f5b8d8". At the end, there are 30 workspaces only on one version. Let's imagine if we have 5 versions on DEV, QA and Production branches then this number is going to be 30*5=150 which is too much.
The solution I am looking for is creating only one workspace that contains all components. In other words, mapping TFS parent root folder that contains all 30 components into one folder in the local disk. Here, one workspace would be created for 30 components and we could use workspaces more efficiently. I think, if this solution works, then Check-in problems also disappear.
Thanks beforehand.
Thanks for the clarification, about your request for creating one workspace instead of 150, I'll forward that internally to see what can be done, but I am not sure how this ties in with the mapping you mentioned, nor with the issue you are facing of first builds failing. As mentioned, TeamCity should be handling this automatically, and the first build should have everything available just fine.
I need to understand exactly what you mean with the mapping and what is exactly failing before being able to help with the actual problem. As you can imagine, using TFS should not automatically make first builds fail, and it doesn't, so something else specifically has to be wrong, which is what I'm trying to get to.
Please try to share with us the exact issues (with error messages, logs, etc) you actually experience when running your first build of a given configuration so that I can try help figuring out what exactly is going wrong.