I have one teamcity server and several agents. Not all of them has gradle installed.
How to limit builds only for agents with installed gradle?
On your build configuration, go under 'agent requirements' and select 'add new requirement':
Include whatever value you want to check for. If Gradle isn't on the path variable, you can add a new variable to the agent and check for the presence of that.
You can check this has worked by looking at the agent compatibility for the build configuration.
Related
I've recently installed TeamCity 2017.2.3 (build 541047) and Octopus Deploy 2018.1.5 and originally was having success running builds and creating packages in TeamCity, but now my build agent shows all of my build steps as incompatible after a service restart.
I've uninstalled and reinstalled the buildagent, plugins (I use Node.JS build runner, Octopus Deploy integration, and xUnit) and rebuilt each of the build steps, but still run into the same problem
Build Step List
Anyone know what would be causing this issue?
Each agent should have a list of global parameters that are picked up from the OS or manually configured from the agent properties file on the machine. These are things like the path, dotnet versions, npm etc.
http(s)://<tc root>/agentDetails.html?id=<agent id>&tab=agentParameters
(You can get to the above by clicking on the agent you want to inspect)
You can then override or add to these from the root project all the way up the project tree to the build configuration.
The message you are getting is saying is that in order for the build to run it needs to have an agent with those parameters configured. Could you give a screen grab of what your build agent parameters are.
Here is an example from one of my build agents which shows some of the configuration parameters that you need.
You should not need to add these, they should be picked up automatically by the agent.
First make sure these dependencies are actually installed.
If missing install and restart the agent service (required to pick up new configuration properties).
Possibly try a machine restart in case newly installed components require a reboot.
Failing that check to see what permissions the build agent service is running under. It might not have permissions needed to poll the system but I have never seen that.
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 came across an interesting issue. I want to build nuget packages with Teamcity. I did set up the configuration which is really straight forward (Good job JetBrains!)
However I am not able to run it on one of our build agents.
The agent does pass the agent requirements for the configuration, but next to it's name the following is shown: not allowed to run this configuration
My question: Why?
On the agent configuration parameters page I have Nuget as possible configurations:
teamcity.tool.NuGet.CommandLine.2.8.2.nupkg D:\BuildAgent\tools\NuGet.CommandLine.2.8.2.nupkg
teamcity.tool.NuGet.CommandLine.DEFAULT.nupkg D:\BuildAgent\tools\NuGet.CommandLine.DEFAULT.nupkg
We have a second build agent which is able to run Nuget Packager configuration.
The main difference between this two machines is that one is a Windows 8, version 6.2 machine (not allowed to run this configuration) and the other one is a Windows 7, version 6.1 (allowed run this configuration)
We are running:
TeamCity Enterprise 8.0.5 (build 27692)
Any hints and help will be greatly appreciated!
Thank you!
Most likely the agent is configured to run only explicitly assigned configurations.
Plesase, check the Agents -> -> "Compatible configurations" tab.
There is a combo box with options "Run all compatible" / "Run assined .. ". Make sure "Run all compatible" is selected
You may not always be in a position to Run all compatible, In that case you can go to Agents--> Particular agent --> comaptible configurations --> Assign configurations --> Search and select the specific Job or build.
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.