I have set up a build step on TeamCity,as described here, to do automatic release deployments to our test server. But it is not using the latest nuget packages that was build in TeamCity.
Use Case :
Teamcity will create nuget package with version 1.0.0.9, all the dlls that is in the package is the correct version, and the Release in Octopus, that was deployed has got the same version number , but the packages that octopus uses is of an earlier package eg 1.0.0.5.
I have specified the --force parameter on the build step so it should use the latest packages but it is not.
If I manually create a release in Octopus, and select the latest packages it is working 100%
Please can someone tell me if I am missing something.
thanks in advance
I think what you need to do is create two build configurations in TeamCity, one to build and one to deploy with Octopus. Refer to this link that has a small blurb toward the end:
Note that NuGet packages created from your build won't appear in TeamCity until after the build completes. This means you'll usually need to configure a secondary build configuration, and use a snapshot dependency and build trigger in TeamCity to run the deployment build configuration after the first build configuration completes.
So in my case I created 2 build configurations, then setup a snapshot dependency from the build to the deploy config and also a trigger to kick off the deploy after a successful build.
It looks like --force is just to force packages to the be re-installed if they have already been installed. Are you using the --packageversion parameter?
My organization uses Jenkins CI. We use the unique build number as our package version and then deploy that specific package version using the --packageversion paramater.
In the case where we have multiple services that need to be deployed. We have an upstream job / main job that provides the unique build number.
I'd imagine you can do the same thing with TeamCity
Master Job (unique build number) calls jobs A and jobs B with parameter (unique build). Jobs A and B build version (from Master Job). Jobs A and B complete then publish their respective versions.
It could be a few things.
Check out.
http://octopusdeploy.com/documentation/integration/teamcity
You haven't mentioned how your consuming the feeds from Octopus in Teamcity. I would start there.
Next I would use the teamcity action to do your deploy. You asked "Where should the --waitfordeployment flag be added" there is a check box to make sure the deploy has worked before the action can continue.
In TeamCity I use a Octo Push Packages step and in the Additional Parameters field I specify the --defaultpackgeversion {VERSION} parameter.
This will force Octo to use a specific version of packages instead of just choosing the 'Latest Version'.
There are more possible reasons for the problem.
To see the problems with Octopus go to Configuration -> Diagnostics
Another common problem is to use a Package Name #{variable} in a deploy step
Currently it is not possible and Package Name should be set manually, for example MyWebSite or MyWindowsService. See UserVoice for this feature.
Related
We have a Mainline build versioned "x.0.0.r" where we publish a web service using octopus. Our branches are versioned "x.y.z.r" for specific releases. We DO NOT want to publish this web service when building from a branch.
We are using TFS: 2013 xaml build def; msbuild args: "... /p:RunOctoPack=true ..."
Short of setting /p:RunOctoPack=false or removing the OctoPack arguments from the branch build definition, is there any other way to NOT run Octopus? Perhaps in the packages.config file, to say if the version is NOT ".0.0." set "\p:RunOctoPack=false"?
We have missed removing this parameter when branching and cloning the build def and have mistakenly published the web service from the branch a few times. Would like to avoid this going forward.
Thanks,
tom
The deployments you describe are a bit confusing. I think you are wanting to deploy all versions tagged with version 18.x.y.z and not deploy any other version numbers.
Using Channels in Octopus would allow you to achieve this, without adding logic into your build process.
In your deployment process in Octopus, you would have a step that is deployment of your application. This is the one that you only want run when you are deploying version 18.x.
In the Channels section, add a channel and create a version rule for the channel. The package step will be the deployment step created earlier, and the version range will be something like [18.0.0,18.999.999.999)
The Version Rule Design screen gives you the ability to add sample version numbers to test your version expression.
This means that all deployments of version 18 will run the package step, and all others will skip it.
You can also get additional help via the Support channels
Here's my project's TeamCity configuration:
TC calls my script (FAKE - F# Make) to build & test my project.
As the final step, the same script creates a NuGet package.
Then I use TC's "Build Failure Conditions" mechanism to see if e.g. the total number of unit tests is not less than in the previous build.
Even if my build fails while running the last step, the NuGet package is published as an artifact.
I guess this is not the case - the build failed, so anything it provides shouldn't be considered as reliable.
I've found a similar question asked ~5 years ago:
How do I set TeamCity to not produce build artifacts when the build fails?
which says there was no built-in mechanism in TC to support that. Has anything changed during this time ? Can't find anything on the net.
I use TeamCity 9.0.
My only solution to this would be to separate out the deployment of the package to NuGet as a separate build configuration. That way, you can setup your dependencies/triggers within TeamCity so that it never deploys if the build step you have in place fails.
The artifact will still be created on the TeamCity side, since, as you stated, I cannot find a way to prevent that if the build fails. However, your actual NuGet deployment will never execute if setup this way because the dependency will prevent it with the build failure.
I am new to team city and i just started using the existing team city configuration. I have a requirement to pass the build number (ex:- 7.6.0.4) generated in a build configuration (01 Build Services Installer) to another build configuration (03 deploy installers). The Build number is generated at run time so it will change for every build. How can i pass this build number to the one of the build step in 'deploy installers' configuration? I am using powershell to run my script and i need to pass this build number to this powershell script.
Thanks in advance.
Team City Screen shot
The regular way to achive this in TeamCity would be to define a Dependency between the builds, then you can access all Parameters from previous builds.
Define a Snapshot dependency between "Build Services Installers" and "Deploy Installers" (if not already done)
You can now access all Parameters of the first build in "Deploy Installers" by typing %dep. - Autocomplete will tell you the rest.
I have a project which is a plugin for an opensource system. In order to run a CI build for the plugin, it needs to be installed into an existing instance of the main opensource system. I have mostly got this working, however, the install procedure for the main system is long and complex, so the build takes forever. It is also awkward to set up as checking out the plugin from git always happens first, whereas it needs to happen after the main system has been put in place so that the right directories are there. The solution I have right now is to use a shell script for the install and then an Ant task for the build, ignoring built-in VCS altogether. Feels hacky, though.
Two solutions come to mind:
Have a persistent install of the main system in the build directory, which the plugin is added to at the start of the build, and removed from at the end. I didi this ith Jenkins and it worked OK, but we are now using TeamCity.
Have some sort of parent-chid relationship between two CI projects, so that the main one is built and then triggers the plugin one, which is built within it. This would allow the main one to be rebuilt whenever it needs to be and avoids the awkwardness of keeping an install of the main system clean between builds.
However, I don't know enough about TeamCity to know if this is possible. Has anyone ever done something like this before?
For your solution number 2 you can try to use the "Build Triggers" configuration, the "Finish Build Trigger" option should resolve your parent-child relationship very well.
In TC, go to your plugin's build configuration, in "Configuration Steps" section select "Build Triggers" (number 5), then select "Add New Build Trigger" and configure "Finish Build Trigger" selecting your main system's build configuration.
To use parent directory in child one, you'll need to use the "Artifact Dependency" (see "Dependencies" section in "Configuration Steps", maybe setting some snapshots between the build configurations too.
Artifact Dependencies:
artifact Dependencies provide you with a convenient means to use the
output (artifacts) of one build in another build. When an artifact
dependency is configured, the necessary artifacts are downloaded to
the agent before the build starts.
Snapshot Dependencies: by setting a dependency of a build (e.g. build B) on other build's (build A's) sources, you can ensure that build B will start only after the one it depends on (build A) is run and finished
Configuring Finish Build Trigger:
finish build trigger triggers a build of current build configuration if a build of selected build configuration is finished
I've started using TeamCity personal builds, via the new Git remote run feature in TeamCity 6.5. Doing a single build works fine; I have a project that compiles from source, and I gave it a Branch Remote Run trigger.
However, it looks like TeamCity only triggers the one project that has the Branch Remote Run trigger applied. I have several unit test projects, set up in a chain with Finish Build triggers, and none of these get run. Furthermore, if I try to start a custom build of one of these unit test projects, I can't use the artifacts from my personal build: I can only pick artifacts from one of the 'official' builds.
Can I get TeamCity personal builds to work with build chains?
With the setup that you have (snapshot dependencies and finish build triggers), you can achieve build chaining by submitted your personal changes to the builds you are looking to trigger. For example, if you have projects A and B where B depends on A - run the remote build against project B and A will be triggered first and B will be added to the queue. Both of these builds will have your personal changes.
If you are using the TeamCity Visual Studio plugin you can select which builds you want to send your changes to and you just need to tick the box for B instead of A.
The finished build trigger won't be fired, but the build chaining means that A must be built first.
More info - http://confluence.jetbrains.net/display/TCD7/Build+Chain
(You have tagged TeamCity 6.5, but 7 has now been released so I have included the documentation for the newer version)
I suppose you should setup your chain not with Finish Build trigger, but with "Snapshot dependencies" feature of TeamCity. And, setup artifacts dependency basing on the snapshots.
Please read about snapshot dependencies in TeamCity here.