on my CI server running TeamCity 8.0 I have a build configuration whose last steps are the creation and the push of a new version of a NuGet package.
I wonder if there is a way to inhibit these two steps if the current build is a personal one.
Any clue?
There's an environmental variable thats exposed in teamcity that can tell you if this is a personal build BUILD_IS_PERSONAL :
See http://confluence.jetbrains.com/display/TCD7/Predefined+Build+Parameters
E.g. using the msbuild runner (you just need to supply the nuget path)
<Project DefaultTargets="Pack" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Pack" Condition="$(BUILD_IS_PERSONAL)!='True'">
<Message Text="Personal: $(BUILD_IS_PERSONAL)"/>
<Exec Command="$(NUGETPATH)\nuget pack $(NugetProject)"/>
</Target>
</Project>
Alternatively, you could halt the condition of build steps using an extra build step. thereby making them conditional:
Add an extra build step that uses the powershell-
if (([environment]::GetEnvironmentVariable("BUILD_IS_PERSONAL","Process")) -eq "True")
{
throw
}
On each build step there is the option:Execute step
If you choose the option "If all previous build successfully" then the step will be passed
If you choose: "Even if some of the previous build steps failed" it will execute.
TeamCity 2020.1 has added support for conditional build steps, and there is a quick shortcut to skip the build step for personal builds.
You could create a new build configuration - leaving out those 2 steps. Then - install the TeamCity Visual Studio plugin (assuming you are using VS) and then run a personal build, choosing the build configuration you'd like to use.
Similar to Jordan's response I think the best approach is to separate compilation from packaging / deployment build configurations. In fact if you use Octopus to deploy then you have to keep the TeamCity Octopus deployment steps in a separate build configuration from the compilation as the NuGet feed doesn't get populated until after the build configuration has been completed successfully.
If make your packaging / deployment build configuration a dependency of the compilation build configuration and set the build trigger to only trigger after a successful build of the compilation build configuration, then it will not trigger after a personal build even if that is successful : -
This way you are always calling the same build configuration for compilation, whether via Developers on VS using the AddIn or Release Team via the Web UI
Hope this helps
We have a similar issue where we only wanted to build-and-deploy our local Apache Maven repository when it has changed.
One possible solution: If your build step is a Command Line (or can be), create a tiny shell script to decide if these step should be run or not.
Related
Just trying TeamCity for our applications, however, when we try to build the project it fails as the projects are built out of order, causing a crash and it failing to continue.
I have manually run MSBuild against the solution file and it runs correctly. Is there any extra configuration we could have missed when setting up the server?
I have the following problem and I'm surprised that I can't find any straightforward solution on SO or MSDN.
I have existing *.pubxml profiles in several of my web applications and I would like to execute post deployment script - powershell script - which reorganizes WebSite and its child applications slightly.
I'm not usign Web Deployment Package - just Web Deploy.
The script is deployed successfully but the problem is - how should I execute it automatically after deployment?
I have two scenarios:
Execute by simply "Publish..." from Visual Studio.
Execute as part of TFS Build definition (TFS 2013).
You can try to define a “Target” by MSBuild to achieve your requirement.
For the first scenario:
The Visual Studio build process is defined by a series of MSBuild .targets files that are imported into your project file. One of these imported files, Microsoft.Common.targets. This file contains a set of predefined empty targets that are called before and after some of the major targets in the build process.
So you can define a "Target" element whose "AfterTarget" attribute's value is set to "MSDeployPublish":
<Target Name="CustomPostPublishActions" AfterTargets="MSDeployPublish" >
<Exec Command="..\PostDeploymentScript.sp1 " />
</Target>
For the second scenario:
You can add a PowerShell build task as MrHinsh`s suggestion.
You should switch to deploying from Build & Release only in VSTS/TFS.
You can then add a PowerShell build task and either point at a script or use Inline if it's short. If it is a script that you use in many builds you might want to write your own build task.
Here is my workflow.
Open Package Manager Console
Update-Package
Build Solution
Check into Plastic Source Control
Build in Teamcity
The problem is I keep forgetting to do #3! This is key because it updates my config files prior to check in. How can I set up a one click method to do 1-3? Or some kind of command line macro.
Have it defined in the 'Build Steps' in TeamCity instead. (under Configuration Settings)
Typically have one build step that would have
Runner Type: Command Line
Step Name: nuget restore (or anything you desire)
Run: Custom Script
Custom script: nuget.exe restore
If you add the necessary steps to TeamCity you wouldn't need to build them before you push into your source control.
I have a multiple project solution and am using Octopus Deploy and TeamCity for deployment.
I have installed the Octopack NuGet package on two projects that I wish to be created as artifacts during the CI build.
I have set the follwing in my build step:
and have checked the csproj files of both projects and can see:
<Import Project="..\packages\OctoPack.2.0.26\targets\OctoPack.targets" />
However, after the build runs one of the projects has been packaged as an artifact and the other one hasn't and cant see what the difference between the two is.
Is there something else I should be doing in TeamCity or in my solution?
I had to set the following in configuration manager on the project that wasn't producing the artifact:
Integration|Mixed Platforms.ActiveCfg = Integration|Any CPU
Integration|Mixed Platforms.Build.0 = Integration|Any CPU
Teamcity then happily produced the package.
Make sure you check in the \packages\OctoPack.2.0.26\targets\OctoPack.targets file to your source control.
We have a large non Visual Studio C++ project which is build via a batch file. I have integrated this up in Visual Studio as a makefile project with customised 'Build Command Line' in the project properties, this works well and has done for over a year.
I am now looking to introduce Team Foundation Server and configure automated builds.
If I build the project in Visual Studio then the project build as normal.
If I use the automated build sever to build the project the build fails every time
The option to view the log file in the build report is greyed out. The report given is
The command "Autobuild.cmd" exited with code 1.
Where autobuild is the cmd file specified in the solution's 'Build Command Line'.
Can anyone think of a reason why this might be the case, I assumed that the build sever would just run the Build command with the project specified in the 'Items to Build' box. If this is the case then I cannot see why it would fail.
There are loads of possible reasons; unfortunately you've not given enough information to answer that questions.
The first thing to try is changing your build definition logging level to Diagnostic. (you can also do this when you queue a new build).
What I also recommend is actually wrapping your makefile in an msbuild.proj file.
Something simple like:
<Project ToolsVersion="4.0" DefaultTargets="build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="build">
<Exec Command="autobuild.cmd" />
</Target>
</Project>
The Exec task has loads of options to customize how the cmd is called and should help you diagnose your error.
In general if you want to take advantaged of TFS builds I'd recommend migrating as much of your autobuild.cmd to msbuild as possible. MSBuild is TFS's "makefile" language, so-to-speak.
In your build definition you have an option of logging, there you can change that to Verbose logging. Maybe you get some information in your log file then.
And for the issue of exited with code 1 I think you will need to add some extra informational lines to be printed in the cmd program and when your logging in TFS Build is active you maybe see more information on it.