I am having an issue with TFS. When we had TFS2008, the build machine was able to clear files from the Build Agent Folders before creating a new build. However, after the migration to TFS2010, the build machine cannot clear this folder and we are getting builds with old files that have been deleted from source control.
Is there any way to get this functionality back? We are currently working with the TFS2008 build scripts and the UpgradeTemplate.xaml in TFS2010.
Thanks
In your TFS Build Definition, what is the "Clean Workspace" on the "Process" tab set to?
It has three options:
All
Outputs
None
An explanation of each options (taken from TFS):
Set to All to delete all existing outputs and sources and do a full
rebuild; Outputs to delete all existing outputs but get only those
source files that have changed since the last build (Incremental Get);
or None to leave existing outputs and sources in place and build any
changes incrementally.
You should set this to All, to ensure you are performing a clean build each time.
The only other post I found didn't have an answer. So instead, I reverted back to running a RMDIR command at the BeforeEndToEndIteration level of the build script.
<Target Name="BeforeEndToEndIteration">
<Exec WorkingDirectory="S:\src" Command="RMDIR /s /q "S:\src\Sandbox_awdbu\""/>
</Target>
This command will delete the build agent folder before the Get Latest command is performed by the build service.
It's not a great solution but it works. This solution will work but I would suggest moving onto the template instead of keeping the old TFS2008 build scripts.
Related
I'm new to TeamCity, migrating from a different CI product, and trying to figure out how to configure a working build for a c++ project on version 9.1.6 of TeamCity.
The problem I'm having is that the agent is deleting my dependency directories right before (or during) the component build, and I can't find a record of why this is happening anywhere in the build log.
The build layout for any component in the system looks like so:
<base-dir>
|
+---<to-be-built>
+---<dependency-1>
+---Include
+---Lib
+---<dependency-2>
+---Include
+---Lib
...so, whatever the checkoutDir is for the component, it is assumed that all dependencies will be found in peer directories, named after the dependency, with no version information in the folder name.
For example, if version 3.0.2 of "MyExe" depends on version 1.1.0 of "SomeLibA" and version 2.1.0 of "SomeLibB", the file system should look like so:
MyExe_3.0.2
|
+---MyExe
+---SomeLibA
+---Include
+---Lib
+---SomeLibB
+---Include
+---Lib
So, to create this build layout, the build configuration for version 3.0.2 of "MyExe" has specified a custom checkout directory like so: "MyExe_3.0.2/MyExe".
So far, so good. The dependencies are configured as artifact dependencies and their destination directory is specified as '../'. This also seems straightforward.
When I kick off the build, though, I see the to-be-built component being retrieved, then I see the dependencies arrive, and then the gradle task I've configured for the build runs, and right at that moment, or just before, all of the dependency directories (SomeLibA and SomeLibB) get wiped out, and of course the component can't find any of its dependencies' include files and compilation fails.
I've turned off 'Clean all files in the checkout directory' on the component and 'Clean destination paths before downloading artifacts' on all dependencies, but this has no effect.
I've only found 2 hints possibly related to this behavior, but I'm not sure why either of them would be causing this problem.
The first is a little warning symbol on the Version Control Settings tab for "MyExe" which says "This directory might be cleaned by TeamCity before the build", referring to the custom directory. But, the directory that's getting cleaned out during the build run is not the checkout directory, it's the checkout directory's parent directory.
The only other possible candidate I can find is that the gradle task I've configured isn't the only task specified when the build runs. Instead of seeing "gradlew.bat myGradleTask" in the build log, I'm seeing "gradlew.bat --init-script C:\TeamCity\BuildAgent\plugins\gradle-runner\scripts\init.gradle myGradleTask".
But, I've looked through that init script, and didn't see anything related to directory cleanup.
I'm stumped. Does anyone have an idea what is going on, and how to work around it so this build can complete successfully? Acceptable solutions have to preserve the build layout requirements above.
The problem here was in disabling "Clean all files in the checkout directory before the build".
Disabling this checkbox has the effect of wiping out the contents of the entire path to the checkout directory.
For reference, see documentation here:
https://confluence.jetbrains.com/display/TCD9/Clean+Checkout
...from which the relevant excerpt is:
Automatic Clean Checkout
If clean checkout is not enabled, TeamCity updates the sources in the
checkout directory incrementally to the required state. TeamCity tries
to detect if the sources in the checkout directory are not
corresponding to the expected state and triggers clean checkout in
such cases to ensure sources are appropriate.
This means that under certain circumstances TeamCity can detect clean
checkout is necessary even if it is not enabled in the VCS settings
and not requested by the user from web UI. In such cases all the
content of the checkout directory is deleted and it is re-populated by
the sources from scratch. If any details are available on the
decision, they are added into the build log before checkout-related
logging.
Enabling this checkbox had the effect of leaving the dependency directories in place.
I have a C++ project for which I need to run a custom build tool on some header files to generate code that is required when compiling this project. In general my configuration works. I trigger a build, VS/MSBuild detects whether the output files are up-to-date and runs the custom build tool only if necessary.
However, a problem arises if the build is run in combination with another configuration of the same project. Both configurations depend on the output files of the custom build tool. So if run sequentially only one configuration should trigger the custom build tool to run. For which ever configuration a build is triggered second the output files of the custom build tool are already present and up-to-date. So there is no need to build them again. Unfortunately this is exactly what is happening. Since the custom build tool takes quite some time to run, this increases build times dramatically.
Another interesting aspect is, that once both configuration have run, I can trigger any of them again and the custom build tool is not invoked.
What I would have expected from the documentation is that the custom build tool is triggered:
If any of the files specified as Outputs is missing
If the file for which I specified the custom build tool was modified later than any of the existing files specified as Outputs
If any of the files I specified as Additional Dependencies were modified later than any of the existing files specified as Outputs
But all of this independent from the configuration for which the build was triggered.
Does anyone have an idea on why this might happen? I checked that the settings for the custom build tool are identical for both configurations. The output files are generated into the same folder for both configurations.
The documentation you're referring to is basically correct but it omits to say that everything in there is basically per project configuration/platform because it uses tracker.exe which depends on .tlog files which by default go into the intermediate directory. So as you figured out, making all configurations use the same location for the tlog files should keep the tracker happy and only invoke the custom build tool when needed, independent of configuration/platform. I'm not sure I'd recommend any of this though, sharing temporary object files might cause you problems later.
Another way to deal with this is adding a seperate project with just one configuration, say 'Custom', and do the custom build there. Than make your current project(s) depend on that project and in the solution's Configuration Manager adjust all entries so each configuration you have now builds the 'Custom' configuration for the new project.
I want to run my (working) msunit tests with teamcity. Within my test, I need several files which I successfully copied using either one of the following ways (when running the tests from within VS):
file properties -> copy to output directory
or copying them using a post build step using xcopy
As post build actions I tried:
xcopy /Y "$(ProjectDir)*somelib*.dll" "$(TargetDir)"
or
xcopy /Y "$(ProjectDir)*somelib*.dll" "$(OutDir)"
As you can see, I have somelib.dll files that need to be copied. This is due to the usage of a library, which I listed as a reference. This lib is copied corretly, but it needs some older (c++) dlls, which are not included in the reference package.
Unfortunately I could not find a way to either get TeamCity to run the msunit test within the bin/debug/ folder, or to copy all neccessary files to the working temp folder.
(My goal is to run all unit tests from several test suites and to gather results from dotCover for all tests.)
What is a good way to deal with this situation? I noticed the possibility to pack files into the assembly as resources, and to unpack them inside the unit tests right before they are needed. I will need the dlls in every test and would like to keet it DRY - is this a wise way to "just" copy the files?
As far as TeamCity is concerned, you can make sure the process works when run from the command line (n the TeamCity agent machine, in the same directory, etc.) and then replicate the same steps in a TeamCity build. Since TeamCity just launches MSBuild as external process and executes the configured commands, there should be no TeamCity-specific peculiarities.
I am trying to add resource files to my Visual Studio C++ project, but my images do not seem to be copying correctly during the build step. When developing within a C# environment, this was easily achieved by right clicking on the resource file(an image or what have you) and editing the "Copy to output directory" option. This option does not seem to exist within the C++ environment. Here is a picture of the C# environment to better illustrate the option that I am looking for:
I tried doing roughly the same thing within the C++ environment but, like I said, the option simply does not exist. Instead it only gives a "content" option, with a "yes" or "no". The tool tip says that this is related to a deployment resource, however the resource is not deployed during the project build. I would also like the entire folder to be copied upon build; here is another picture:
Does anyone know how I can replicate this within a C++ environment?
EDIT
I tried using a post-build event script, but nothing appeared in the output directory. I am trying to copy the "Resources" folder, which I show in the second image. Here is the script that I am using:
xcopy "$(ProjectDir)Resources" "$(TargetDir)Resources" /e /y /i /r
Did I do something wrong in that? I don't even see any errors in the build log.
Your post build script worked for me. Yes, it is disappointing that the C++ project solution does not make doing so easier.
Add the project output to the installation project as content Files
I'm setting up an TFS 2010 Build server.
But I currently have the problem that projects with an "custom build tool" won't build because of "no access".
The projects are C++.
The custom build tool is "Pro*C". Basically, you have an *.pc file, and it generates an *.cpp file.
But on the build server, the directory/files are readonly. So it will crash on "no access".
I have tried to remove the *.cpp file from TFS. So that the generated file does not exists. But apparently the folder is also readonly and won't allow to create a new file.
Does anyone has a workaround for this?
I would suggest one of these options:
Don't put the .cpp files in source control if they are generated by the build process
Change the settings for Pro*C to write its output files to a writable intermediate folder
Add a build step that copies the problem files to an intermediate location for processing
Add a build step that forces the file access on those files to be readable for processing
If you only need to build those files occasionally, then build them manually with Pro*C on your developer machine and check in the results, so you don't waste time unnecessarily rebuilding unchanging files with every desktop or build-server build.
There is a project called MSBuild Community Tasks, which can be downloaded from http://msbuildtasks.tigris.org/. I used it for my own for an automated tfs-build.
It provides you with several extensions for your msbuild-project. One of this is the so called Attrib task, which gives you the opportunity to change file (and probably folder) attributes out of you project. It's not listed in the table on the website, but its documented in their documentation. As a sample from their documentation, you can add the following line to a target of your choice:
<Attrib Files="Test\version.txt" ReadOnly="true" Hidden="true" System="true"/>
I think this will also work for an item-group as follows
<Attrib Files="#(AllYourFiles)" ReadOnly="true" Hidden="true" System="true"/>
If you want to use it, don't forget to install it on the build server. ;)