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.
Related
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 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 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.
We have several projects undergoing, and there are dependencies relationships among them. All projects makes up a final software.
We set up a DEV build environment to do snapshots build by using LASTEST dependencies. Any change will trigger a snapshot build (jekins job) and all dependent's snapshot build will be triggered too, and so if any changes break some project, that project's own build will notify the owner.
The question is about the release. The DEV build is continuous, and we want to release EVERY project against certain timestamp when it was a GREEN dev build across all projects.
How to get such release process setup?
thanks.
jenkins provides some Post-Build-Actions. You can use them to publish/archive every successfully built artifact to whereever you want.
Your Release-Job can take all the artifacts and deploy them. So you're sure all artifacts are from GREEN builds and is also independent from all the continuous jobs.
If you want to be really cool, do some smoke tests (e.g. is database connection working, external APIs working, etc) in the Release-Job as well.
best,
marco
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.