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.
Related
I have a team city build configuration , which picks up data from bit bucket and packages it to transfer to udeploy. There is no code build process , it is just simple package and transfer process. All i want is that my team city build configuration should pick files only which are newly committed and never been picked up in previous team city builds. How do i configure this build component to enable this feature.Appreciate you help !
Checkout the Configure and Run Your First Build documentation. The steps you will need to pay attention to are:
Setting the VCS Root. This is how Team City will know when source code
changes.
Automatic Build Trigger. Even though you are not going to
build code, you will trigger your "build" steps on changes in this
repository.
Configure your "build" steps to do whatever packaging
logic you need. You can add a deployment configuration to deploy the packaged product at this point.
TeamCity 8.1.4 (build 30168)
I notice that Build Features are always run as first part of first step in the Build Steps, but is it possible to make a Build Feature run e.g. as first part of step2? Or as last part of Step1?
Any help is appreciated!
(If it is of interest, this is my concrete problem;
I have a meta runner that creates a specific build number, I use this as a first step in the build steps. I want to use the build feature "AssemblyInfo patcher", but this runs before the meta runner has done its thing)
Create another build configuration, move your meta-runner there.
Modify your build parameter to report a build number through service message
Create a snapshot dependency from your build configuration to the new one
In the configuration with meta-runner go to general page, enter %dep.META_RUNNER_CONFIG_ID.build.number% to 'build number' field. This will take a build number from the dependency and set it as a build number. META_RUNNER_CONFIG_ID is the Build configuration id you will see on the general page of your configuration where you have moved meta runner.
Use %build.number% as a replacement in AssemblyInfoPatcher
I was wondering if someone would be able to explain what Build runners do and also what i would need to use for just a static HTML / CSS / JS site, or even an already compiled .NET site.
I will be hooking up each project to its equiv SVN and grabbing updates from there, but not 100% sure what the build runners do or which i should use as technically i dont need to build the site.
Sorry it may be too much to answer but i am just struggling to get my head round Team City
Thank you
Build runners are just a process for a specific task, for example the MSBuild runner is set up by putting information into specific fields which it then uses to call MSBuild on the target build agent. You could just as easily use the Command Line runner and build up the MSBuild run command manually.
Build runner is a part of TeamCity that allows integration with a
specific build tool (Ant, MSBuild, Command line, etc.). In a build
configuration, the build runner defines how to run a build and report
its results. Each build runner has two parts:
server-side settings that are configured through the web UI
agent-side part that executes a build on agent
You need to choose your runner depending on the task that you want to do and the technology that you have wrapped your project in. If there is no runner for your specific task then you can use the lowest common denominator which would be the Command Line runner.
The way I approach this would be to see how I can achieve what I want to from my own environment be that calling a rake, MSBuild or batch file. I then see how I can then apply that to a tool. Do not create a process around a tool but choose a tool that fits to your process.
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.
The group that I work in has standardized on Jenkins for Continuous Integration builds. Code check-in triggers a standard build, Cobertura analysis and publish to an Artifactory SNAPSHOT repo. I've just finished adding a new target to the master build file that'll kick off a Sonar run but I don't want that running on every check-in.
Is there a way to schedule a nightly build of a specific build target in Jenkins? Jenkins obviously facilitates scheduled builds but it'll run the project's regular build every time. I'd like to be able to schedule the Sonar build target to run nightly.
I could, of course, create a separate Jenkins project just to run the Sonar target on a schedule but I'm trying to avoid that if I can. Our Jenkins server already has several hundred builds on it; doubling that for the sake of scheduling nightly builds isn't very desirable. I looked for a Jenkins plug-in that might facilitate this but I couldn't find anything. Any suggestions?
Here's one way to do it, if you are ok with triggering the build using cron or some other scheduling tool:
Make the build parameterized, and use a parameter in your build file to decide if the Sonar build target should run or not.
Trigger the build remotely by HTTP POST:ing the parameter values as a form to http://[jenkins-host]/jobs/[jobname]/buildWithParameters. Depending on your Jenkins version and configuration, you might need to add an Authentication Token and include this in your url.
Authenticate your POST using a username and password.
wget --auth-no-challenge --http-user=USERNAME --http-password=PASSWORD "https://[jenkins-host]/job/[jobname]/buildWithParameters?token=<token defined in job configuration>&<param>=<value>&<param2>=<value2>"
I am also looking for a solution for this. My current solution in my mind is to create 2 triggers in the regular build, one is the nightly build, another one is Polling SCM
In the sonar plugin configuration, it has the options to skip the builds triggered by the SCM change. Therefore, only the nightly build will start a sonar analysis.
I didn't get a chance to test it now, but I suppose this will work.
Updated on 12/19/2011
The above solution doesn't work if the sonar analysis is invoked as a standalone build step. To make the sonar analysis run conditionally, you could use the following 2 plugins:
Conditional BuildStep Plugin - this allows the sonar analysis to be run conditionally
Jenkins Environment Injector Plug-in - this allows you to inject the variables to indicate how the build is triggered.