I have a TeamCity build configuration where step 2 is packing a NuGet package and step 3 is publishing the NuGet package to an external build server.
At least that was my intention.
When I omit step 3 the build is success and the package is created and placed in the directory I specified in step 2.
When I include step 3 it fails because TeamCity has not yet placed the created NuGet package at the specified destination.
Am I approaching this the wrong way, do I perhaps need another build configuration with publish that depends on the first build configuration ?
It turns out when packing NuGet packages to an external resource like I first did, example \\foo-server\temp\\nuget the NuGet packages would not be copied to the destination until the build was complete, after step 3 should execute.
Solved it by just using 'nuget' as destination directory, creating a temp folder in the checkout directory of the Build Agent. By doing it that way the packages are available inside the build configuration so step 3 can access them.
Related
I have 2 configurations in the teamcity which refer to 2 separate repositories in the mercurial. When starting a build the project updates all its files. Can we configure 1 build agent to have 2 reprositories so that only the changes of the corresponding project are taken and not all files of the project at updated when starting the configuration? Or do we need to create 2 agents?
If TeamCity decided to clean checkout directory on an agent, it should log why this happens into the build log of the build.
Possible reasons of clean checkout are outlined in documentation: https://confluence.jetbrains.com/display/TCD18/Clean+Checkout
What is the set up required to move files between builds in TC? I am needing to move both modified source files and build binaries between the build configurations of a build chain.
I have 1 project with 4 builds. The builds are
Update Version Number (This build updates 15 sources files)
Compile (This build compiles a dozen objects)
Test (This build runs a regression test)
Create Package (This build creates a setup.exe file)
Information about the TC setup and chain
I am using perforce as my VCS.
All 4 builds use the same VCS root.
On all 4 builds under version control settings I have "Clean all files before build" set to "On".
"Update Version Number" build is triggered by any check in to the VCS. (This works)
I have been able to successfully chain and trigger the builds. However each build starts with a fresh copy of files from the VCS.
The chaining is set up to use snapshot dependency.
Based off of the TC documentation it looks like I should be using snapshot dependency and not artifact dependency. If I put the build steps of all the builds into the same build everything works. However we are looking to have more flexibly and expand on this build chain in the future.
I tried setting up the configuration so only the first build is attached to the VCS root and the other builds don't have any VCS root. This didn't work.
I have been unable to find the answer googling but I have been able to find someone else who is struggling with this problem. Sadly they didn't receive an answer.
After speaking with TC customer support I learned the correct technique is to use both artifact dependency with "build from the same chain" selected and snapshot dependency.
I have big problem with configuring TC. It's 10.0.2 version.
I want build chain like this:
Main - Restore nuget and rebuild solution.
Code analysis - Analyse code result(do not checkout) use Main as dependency.
Publish - Publish to Azure - Use result of Main.
I set Main to:
Build numer format:%build.counter%.%build.vcs.number....%
VCS checkout dir: auto
Code analysis
Build number format:%build.counter%.%dep.<mainId>%.%build.vcs.number...%
VCS checkout dir:%dep.<mainId>.build.default.checkoutDir%
And the main dir is: 55660246e9f668c3
And Code Analysis searching in: 9ccd5731845f5aba
So it's wrong. Why?
Why?
EDIT:
What I set VCS checkout directory in "Code Analysis" build configuration to hardcoded directiory name of "Main" e.x. to 55660246e9f668c3 then it work.
So the problem is with %dep.<mainId>.build.default.checkoutDir%
You can set up a snapshot dependency, that builds from the same chain. This will ensure that the same branch, from the same root, with the same revision number (point in time) is checked out to the directory. If you use an artifact dependency, in addition to the snapshot dependency, you can achieve the same point in time consistency. So after your step 1 build runs, regardless of what new changes exist, your second build will be working with the same files your first had.
I am doing the following steps:
dotnet restore
dotnet publish
octopusDeploy: Push packages
The second step creates a 'published-app' folder and the third step is meant to take that and create a .zip file and send it to the Octopus server.
The third step is connecting to the Octopus server but gives the error:
Running command: octo.exe push --server http://server.com/ --apikey SECRET
Pushing packages to Octopus server
Please specify a package to push
I am following this https://stackoverflow.com/a/38927027 so my third step has:
%teamcity.build.workingDir%/published-app/**/* => App.zip
Any ideas why the zip file is not being created?
Not sure if you ever got this working for yourself, however just in case it helps anyone we recently came across the same issue deploying an AspNetCore 2.0 web application running on net471 being built by TeamCity 2017.1.4 (build 47070).
After some tinkering I noticed that the "OctopusDeploy: Create and Push Packages" build step ran at our git checkout root directory, so I ending up having to use the following values for the "Package path patterns"
%ProjectDirectory%/published-app/**/* => %ProjectName%.%GitVersion.NuGetVersion%.zip
NB: %ProjectDirectory%, %ProjectName% and %GitVersion.NuGetVersion% are build parameters we have manually defined elsewhere in the build process that TeamCity can replace. %ProjectDirectory% is simply the application's source directory relative to the root of the git checkout i.e. WebApplication1 so the full path would be <full checkout path>/WebApplication1
Another gotcha that we experienced was that at the time of writing the combination of TeamCity and octo.exe (from Octopus.TeamCity v4.15.10) didn't like creating nupkg files, so make sure you try to produce a ".zip" file. In the error instances we would receive the following error:
Error from Octo.exe: Cannot run program "C:\BuildAgent\temp\buildTmp\octo-temp\3.0\octo.exe" (in directory "C:\BuildAgent\work\4e62985fa616fa1f"): CreateProcess error=206, The filename or extension is too long
I have created a Smart Device CAB Deployment Project and contains dependencies eg: Test.dll.
Where Test is a seperate class library. I have created a build definition for this solution(contains Test Proj + CAB deployment Proj). When i trigger queue new build for this definition Test.dll is not getting updated in CAB deployment project in Build Agent folder of TFS Server.
PLease let me know how can i reload this dependencies on checking in / queuing new build.
Thanks in advance
Check your Workspace option on Process tab. It should be All or Outputs if you wish to have always fresh version. None option is for incremental builds. If your project is really small "All" is the best option for you.
All - erase entire workspace and download and build everything again
Outputs - like All but only output bin folders are erased and new
version is downloaded (get latest version) from source control.
(incremental get) (like Rebuild (cleen + build) in your solution)
None - sources are build incrementally. Like Get latest version +
Build command in VS