I am doing builds using a custom MSBuild Script in TFS2010 SP1. The Build Type is a gated Check-In and fails even though the MSBuild log shows as successful on my builds. What would trigger a failure after MSBuild is complete and before The build definition finishes the gated checkin
It turns out that the DataCollectors were failing as the test runs were happening. This was diagnosed in the event log under VSTT. Unfortunately it doesn't update the normal MSBuild logs and no other information is given into the Workflow logs.
I ended up disabling the datacollections in the local.testsettings file that is being used as part of the build process.
Related
Whenever I clone a repository, I see on the GithHub page a certain icon indicating the build - for example build passing.
I am extremely new to professional code development. I would really appreciate it if someone could tell me what a particular build status indicates ? Brief answers would do !
Software projects consist in a set of source files, and of an automated procedure used to "build" the executable product or library. This procedure is called "the build". It can fail for various reasons:
compilation error
automated tests failing
coding conventions not respected
bug in the build script
etc.
"Build passing" indicates that the build procedure completed successfully. "Build failed" indicates that the build procedure failed.
Usually, this build procedure is executed automatically each time a new commit is made on the repository. A continuous integration server like Travis or Jenkins downloads the project for the last commit, then launches the build, checks that it succeeds, and updates the build status.
I've recently moved to TFS213, did an install on a new machine.
After building one of my projects the result showed an error on MsTest. It turned out that it had invalid switches (as in Error when running unit tests from MSBuild)
Invalid switch "/publish".
Invalid switch "/publishbuild".
Invalid switch "/teamproject".
Invalid switch "/platform".
Invalid switch "/flavor".
I have found various posts online about this and have done the following :
I have installed vs2013 professional on the build-machine, in various posts it's says to install ultimate but I don't have a license for ultimate.
The problem still persists, the MsTest.exe is started from the correct location (it's only installed in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE, and the build-process does find the MsTest executable.
for now I've disabled testing in my build-definition but that's not the 'ideal' situation ;-).
Should I just remove the invalid 'switches' or is there some other solution
TIA,
Jurjen.
I had the same issue and solved it by modifying the properties of the "Run MSTest for Test Assemblies" step in the build.
Summary of fix: I changed the Flavor, Platform and Publish properties of the "Run MSTest for Test Assemblies" step to "" (empty string).
Details of fix: I did this in a custom template but I think you could also make the change in the default template.
Disabled tests (as you did) to make sure my build would work as a baseline.
Followed instructions here to create and use to a custom template:
http://msdn.microsoft.com/en-us/library/dd647551.aspx
Tested that the Custom Template worked by adding a "Write Build Message" step to the build (per advice in article above).
Searched for (drilled down) to the "Run MSTest for Test Assemblies" step in the build. This took a long time because it is deep. I am sure there is a faster way to find it but I am not sure how.
Set Flavor, Platform and Publish properties to "" (empty string). (See photo).
Committed template changes to TFS.
Re-ran the build and it worked.
When all tests pass I don't see test results on the build results screen.
When a test fails it causes the build to fail. I don't see the test failure in the build summary but it does show up when I click "View Log".
This isn't ideal, but at least I have the tests running and preventing a build from passing when a test fails.
I have been playing around with TeamCity to get a CI environment up and running.
I started by following Troy Hunt's 'You're deploying wrong', which was very useful, however I wanted to split the packaging and deployment into 2 seperate steps, for the following reasons:
I wanted to pass some additional flags to msdeploy, which isnt possible (to m,y knowledge) by using the MSBuild Package and Deploy that Troy describes.
I can easily disable the Second Build Step i.e. deployment, if I ever need to build the package but not deploy it.
I wanted to use the -skip flag on msdeploy to prevent it from deleting certain folders, which again I couldn't find any method of doing without passing as an argument to the command line.
So, in my first MSBuild step I just have the parameters:
/P:Configuration=%env.Configuration%
/P:VisualStudioVersion=11.0
/P:IgnoreDeployManagedRuntimeVersion=True
And then I have a second Build Step that uses a command line build runner to execute the following msdeploy command:
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package="C:\ProgramData\JetBrains\TeamCity\system\artifacts\MyProject\%system.teamcity.buildConfName%\%teamcity.build.id%\MyProject.Web.csproj.zip" -dest:auto,ComputerName='https://devserver:8172/msdeploy.axd?site=MyWebsite',UserName='domain\username',Password='password',IncludeAcls='False',AuthType='Basic' -skip:objectName=dirPath,absolutePath=media$ -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -retryAttempts=2 -allowuntrusted
The problem with this is that apparently TeamCity doesnt publish the artifacts until all the build steps are complete, so therefore the Command Line process fails because the package zip file doesnt actually exist at that point.
I have read something about publishing artifacts whilst the Build is still in progress but that does seem like a bit of a hack.
Any advice would be greatly appreciated.
You would be better have two builds vs two build steps.
The first (Build A) would have 1 build step that would do the building then the second (Build B) would just do the deployment in one build step using the artifacts from the first.
So under the first configuration tab of build A, you would specify the artifacts that would need to be made available from the first build. You can then run the build and confirm that under the artifacts section everything you need is available. (These will show when build A has completed running).
Then under the dependencies section (Can't remember the exact name, and I'm away from my TC instance) of Build B you can set it up to use the artifacts of build A which would then be used for the deployment.
Once you have all that working, you could add a build trigger to have Build B run after a successfull execution of Build A, then if you at one point just wanted to run Build A, disable the trigger on build B or pause the Build B configuration which will stop the trigger from firing.
I build my solution but CC tools are not installed on build server.
So no rewrite was done.
Now I'm curios why msbuild reports build as successfull if not all tasks were finished?
P.S. I'm completely unexperienced in msbuild so if my question sounds stupid I beg you pardon, guys.
Update
Well, I installed locally Code Contracts extension which created additional tab for project options.Then I enabled code contracts checking at run time and added at the very begining of the Main method the following line:
// test for Code Contracts rewrite
// exception is thrown if no rewrite
Contract.Requires<Exception>(true);
I commited changes to TFS and started the build and it completed succesfully without any warnings. No rewrite was done and my application throws exception.
I've read about Microsoft.CodeContracts.targets file ad found it in CC installation dir but I see no refernces to it inside project file. Only elements like <CodeContractsAssemblyMode>1</CodeContractsAssemblyMode>.
I don't understand where msbuild gets the knowledge about CC and how to apply them.
Update 2
Eventually we installed Code Contracts on Build Server and assembly instrumentation is performed.
Yet it's still not clear what settings are changed during CC installation.
You need to install the tools on the build server as well. The design of the contract tools are such that unless you use Contract.Requires< Exception >(...) one can build and release bits without the use of our tools. If you use Contract.Requires< Exception >(...) however, then you must use the rewriter as the documentation states. Thus, in order for your project to be successfully built, you need to install the tools.
MsBuild and VS and C# know nothing of the contract tools and thus cannot warn you about this lack of tool installation.
Hope this helps.
I'm wondering if there is a way to force TeamCity to run a given build step even if preceding build steps fail. I want to do this to clean up after the build and terminate any started processes etc.
In Msbuild you can set the property ContinueOnError for many tasks. I usually add this using a property so it can be switched on and off:
<MSBuild Projects="my.csproj" ContinueOnError="$(ContinueOnError)"/>
Then you can set it on and off via teamcity.
So if you do this for a build step it should continue thru to the others.
I don't know if you can do it with build steps, but I've done it with two builds. The second one uses a finished build trigger pointing at the first. Finished build triggers can be configured to fire even if the first build failed.
We do our builds by constructing NAnt scripts, and then using TeamCity's NAnt runner. NAnt (well, actually NAntContrib, but still ...) has a try ... catch ... finally mechanism that does what any programmer would expect - run the catch code if the try code fails, and run the finally code no matter what happens. We use it for the same purposes as you want, plus to collect artifacts that we want the build to publish even in case of failure (like test logs).
Newer versions of TeamCity has this feature built in.