According to my post:
Build Definition XAML -> TFS2015
which is duplicated with:
How to handle multiple configurations in VSTS Release management?
I have one more question about Build Proces in TFS 2015. can someone tell me how can I set two outputs path after build? I mean one for x64 bit and second for x32 bit during one build process?
../Release/x64/..
../Release/x32/..
Build Platform is set to "MixedPlatform". I did try also with "Any CPU" without result...
My configuration is in the first link.
I'm assuming you have a multiplier set up on the BuildConfiguration or BuildPlatform variables, or on both, so that the build process runs multiple times for each permutation.
In that case, you just need to override your output path (usually /p:OutDir=(some path)). In this case, you'd override it to $(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\$(BuildPlatform). That will put the outputs for the current permutation of your build to a specific folder for that permutation.
Then, in your publish artifacts task, make sure you're publishing an artifact pointing to $(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\$(BuildPlatform) with a unique name, like Web_$(BuildConfiguration)-$(BuildPlatform)
Then, when the builds are all done, you'll have multiple sets of artifacts attached to the build, one for each permutation. You can then consume those artifacts down-stream in a release definition.
Related
I have a "SOA" styled application, with a single solution containing almost 100 individual projects (which are a solution within them, i.e. they can be run independently). I have created a build and release definition in TFS 2018 and everything works perfectly.
The issue is if I make changes to a single service (out of 100), and check-in my code, the build definition is triggered which builds the entire application and then the release definition deploys the entire thing(100+) each time.
I don't want it. I need it to be specific to the service in which changes are made. Is there any way to do it?
Creating multiple build/release definition which is tied to the specific path of each service should solve it but I don't want to go down that road, because I will end up creating 100's of definitions.
Is there any other way to do it?
This is for a .Net application, hosted in TFS 2018 (On-premise).
The solution structure is as below:
AllWCFService.sln
|_Service1.csproj
|_Service2.csproj
|..
|..
|_Service100.csproj
Each Service can also be run and hosted independently.
This is my first question here. I apologize for any confusion.
As you have mentioned, by using Path filters on the Build definition should be the easiest solution.
With the proper path to the project in the Path filter only the proper Builds spin up, and any projects untouched do not trigger a build. Each build has it's own release which then deploys the specified app to it's own destination. As a ugly workaround, you could set up a group each with 5 services which will reduce 100's of definitions to 20's.
Otherwise, you have to customize your build definition/pipeline. Use some scripts to determine or judge which part of your Servicex.csproj changed base on your name.
Then call msbuild with /t option to build a single or multiple projects.
msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false
specify project file of a solution using msbuild
It will only build specified changed project and generated corresponding artifacts. Then add scripts in release to specify path according build generated artifacts to deploy each service.
Hope this helps.
We use a nice $(date:yyyy.MM.dd)$(rev:.r) build number format in our day-to-day agile sprints. However, the release must be numbered with a simpler 1.0.0.rev schema.
Ideally, I would like to give the build number as a variable, which would be automatically expanded in the "queue build" dialog, where it would be possible to be overriden. How can it be done?
I tried moving the $(date:yyyy.MM.dd)$(rev:.r) format to a variable, and use that variable in the general tab, and got error 400.
You could directly use Environment variables such as Build.BuildNumber /BUILD_BUILDNUMBER
Using this just equals to the name of the completed build. You can specify the build number format that generates this value on the General tab.
If you just want to generate custom build numbers like 1.0.0.rev schema in TFS Build vNext. You can take a look at below blogs:
Generate custom build numbers in TFS Build vNext
Managing vNext build Version Numbers
This is very simple.
1) Just create a Powershell script like this
$FinalVersion=Some-Function-To-Calculate-Version
$BuildDefName = $Env:BUILD_DEFINITIONNAME
Write-Host "##vso[build.updatebuildnumber]$($BuildDefName)-$($FinalVersion)"
2) In your vNext build definition, for "Build number format" just set it to anything. It doesn't matter because the Build Number will be overwritten.
3) In the same vNext build definition steps, add the first step as a Powershell step, and set your script from step 1 to be executed. You can later customize if you want to pass variables in order to calculate your build number.
4) Queue your build and see the results.
So I want to have a number of different websites running identical copies of binaries, but with differently transformed config files. These are different regional 'copies' of basically the same website (but connected to different backend DBs etc.)
I have a jenkins job which builds my asp.net site, e.g.;
MSBUILD
C:\Code\ProjectX\src\Website\adminsite.projectx\adminsite.projectx.csproj
/m /p:Configuration=Debug /p:OutputPath=C:\Code\ProjectX\build\Website\adminsite.projectx /t:Rebuild
When that job completes I want it to trigger a transform of the .configs, and a deployment of the binaries. Is there any recommended means of achieving this?
Right now there are only 2 different regional versions of the site deployed, each with their own web.config transformation file
I know that I could have each region BUILD its own copy of binaries, and do a straightforward deployment. But both regions will have identical binaries, so it seems like a waste of time for them to both kick off a build...
If both jobs try to build from the same source location msbuild seems to be producing artefacts in sub-folders of that location - so when both are kicked off at the same time they're tripping over eachother...
Any suggestions? :)
For what it's worth msbuild seems to ignore OutputPath when I provide that
That would have been ideal because I could just use something like;
/p:OutputPath=c:\Code\ProjectX\Build\$(Configuration)\.... etc.
I found that least wasteful way is to build (or "prepackage") once and include the trasforms into the artefact for environment-specific transformations and deployment later. Basically you'll have a custom MSBuild project, on build it'll call PipelinePreDeployCopyAllFilesToOneFolder target (less wasteful than Package since we don't need the final .zip) and redirect it with _PackageTempDir property and include all Web.*.config items, then on deploy you'll call the appropriate transform task and deploy via msdeploy sync.
Having real problems creating artifacts in teamcity 6.5 (using TFS & MSBuild as the buildrunner if it makes any odds, which it probably does as any examples I find seem to use SVN...).
The Build works, so long as I enter no checkout rules.
If I understand it, I'll need to set up some artifacts, that themselves rely on checkout rules(?).
I have two builds that are identical other than the way they are kicked off.
One is initiated on check-in
One is initiated manually from within TC. This build is the Test Build
Assembly version numbers come from a single versioninfo.cs file that is a linked file in all projects in the solution. This method is detailed here : http://www.codeproject.com/Articles/328977/The-Right-Way-to-Version-Your-Assemblies and holds the version number thus:
[assembly: AssemblyFileVersion("9.1.0.0")]
Ultimately, I'm unable to copy the output of the test build to another location.
As it stands, the only output of a build is in the teamcity data directory, for example :
C:\TeamCity\buildAgent\work\ceaaf65dc87ff856\Project1\bin\Debug
C:\TeamCity\buildAgent\work\ceaaf65dc87ff856\Project2\bin\Debug
etc
I'd like to copy the output files (exes and DLLs) to an output folder which has the build number of the build on it
For arguments sake, lets say for the version number above, this would be to
c:\BuildServer_Output\SolutionName\9.1.0.0
Currently I have not been able to create artifact paths that actually do anything - i.e. to copy anything anywhere.
For instance I have acoupe of artifact paths, but nothing ever gets put into C:\BuildServer_TestBuilds -
+:Accounts\bin\debug* => C:\BuildServer_TestBuilds
+:BackOffice\bin\debug* => C:\BuildServer_TestBuilds
Am I getting no artifacts (and my artifact paths therefore ignored) because I have no checkout rules?
Any help would be appreciated.
I am pretty sure artifacts and checkout rules are completely independent. Artifacts just deal with what has been built. Checkout rules tell teamcity how to react to and checkout changes in the VCS.
It looks like your artifact paths are beginning with absolute paths. I have always found it easier to use relative paths with wildcards. That way I don't need to worry about where teamcity put the build. We use the following to get all dlls and exes to one folder
**\bin\Debug\*.*=>deploymentdir
Our build configuration page has an artifacts link and when we open it it will have things like
deploymentdir\common\bin\debug\common.dll
deploymentdir\common\bin\debug\common.pdb
deploymentdir\runner\bin\debug\runner.exe
In one of our other builds we use an msbuild script to flatten our output before putting it through the artifact process.
We do use checkout rules but we have not had to change our artifact paths to accommodate them.
We are using TFS Build 2010 for Builds. We have two branches of source code (Lets say branchA and branchB).
Now as a part of the build definition we set the projects to build:
Now to employ the same build definition from branchB will mean that I create another build definition file with same content, with only the items to build set to "$/branchB"
Is there anyway to make this configurable, without having to edit the build definition?
Also there are other input variables that we set for the build definition, and the values for these variables are included in the build definition XAML file. So to change the value of a variable will mean that we have to edit the build definition XAML file. This is not desirable.
I would like to be able to set the "Items to Build" and the variables of the build definition without having to modify the build definition XAML file.
Are there any solutions to these problems?
You can modify the Build Process Template so it only asks you for the Items to Build. The rest of the arguments are prefilled. To get an idea how this works, see http://www.ewaldhofman.nl/?tag=/build+2010+customization
You can add parameters to your build definition. I did this a while back because we had two web projects in a solution that had to be deployed to different servers (via Windows shares). I added parameters to the build def so that in the build properties I could customize them depending on if it was a dev deployment, staging, etc.
I added a blog post on how to do it. You can use the parameters this way so that they aren't kept in the XAML file.
Deploying Web Apps with a customized Build Process in TFS