2

In TeamCity, is it possible to parameterize the agent requirements based on project or build configuration parameters? E.g. can value include %...% substitutions?

An example: we have a project parameters env.XXX_VERSION which specifies the needed version of the XXX product in all the build configurations of the project. We can then use this value in the relevant build scripts of the project. (Over time we make copies of this build project for different variants of some of the products we depend on, so we now have 12 different projects with different values for the parameters). Now I also would like to include an agent requirement from all the relevant build configurations in the project so only the usable agents will be considered. But given the number of build configurations and the number of variant projects, I would prefer to parameterize the requirement on the value of the exiting env.XXX_VERSION. Is this possible?

(Today, all our agents includes all possible versions of the software, but will no longer be possible, so we will need requirements on the agents from the projects of build configurations)

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
Tonny Madsen
  • 572
  • 2
  • 7
  • 17
  • Hi Tonny, have you ever been able to find a way to parametrize the requirements? I am finding myself _exactly_ in your described situation and would love to know that it is indeed possible. – Leonid Usov Apr 23 '18 at 16:50
  • Leonid (sorry for the late response), but no, we have not found a way to do this apart from using the new Kotlin DSL of 2018.1. Now we actually generate all out configurations from Python code and then "install" them via the Versioned Settings support... – Tonny Madsen Jun 25 '18 at 13:31
  • Nice, thanks for the reference, I haven't heard of this option before. Started investigation. In the meantime, could you please briefly describe how exactly the usage of the versioned settings allows for this kind of dynamic agent selection? Are you somehow adding the agent requirements as a hard coded configuration section, regenerated for every build automatically? – Leonid Usov Jun 27 '18 at 08:51
  • (late, but...) That is exactly how. One can say that we just resolve all the variables when we generate the configurations. Of cause, this also means we can do al sorts of manipulations, so the substitutions need not be "linear". – Tonny Madsen Sep 03 '18 at 20:02
  • (late, but...) This also means we can do all sorts of manipulations, so the substitutions need not be "linear". We have set-up the generation, as a build configuration with dependencies on all needed files, so anything that will change the configuration will automatically run the generation. Versioned Settings is simple: the configuration of TeamCity is stored automatically in a VCS (e.g. Git). This is a two-way thing: changes in the VCS will be detected automatically and TeamCity will align its configuration. So our generator "simply" stores the wanted conf in the VCS... – Tonny Madsen Sep 03 '18 at 20:26

3 Answers3

2

It seems like you already know what you want to do and the issue is the large number of agents and configurations that you need to deal with.

Why not automate this using TeamCity's REST API? TeamCity's server has a built in HTTP API that you can use to edit/update (almost) any of the fields you would be able to using the web interface.

You can interact with the API using your preferred scripting language using HTTP GET/PUT calls to get and update values. In this case, I think it would be worth your time to write a script to avoid having to go through the UI to update all the build configurations you mentioned.

You'll write a single script (in whatever scripting language you're comfortable using) that you can run once to set all the agent requirements. Pseudo code following

  1. Iterate over the projects in TeamCity

Get the list of projects

curl -i -H "Accept: application/json" http://teamcity/httpAuth/app/rest/projects --user username:password
  1. Get the XXX_VERSION parameter from the projects.

Loop over all projects, get all parameters and parse our XXX_VERSION

curl http://teamcity/app/rest/projects/id:PROJECT_NAME/parameters
  1. Set the agent requirement on the build configurations.

For each build configuration, in each project, set the agent requirements on the build configuration using the parsed out XX_VERSION value

curl -X PUT http://teamcity/httpAuth/app/rest/buildTypes/<buildTypeLocator>/agent-requirements/<id> --user username:password

This is the general idea but not complete, by spending time getting this script out of the way you'll save a lot of time managing it via TeamCity UI.

https://confluence.jetbrains.com/display/TCD9/REST+API

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
kdtong
  • 46
  • 3
  • I cannot see how this would work. Please explain further. – Tonny Madsen Aug 12 '16 at 17:13
  • Tonny, I updated with some additional details. You'll have to excuse me for it not being fully complete. Hope it helps or at least gets you along the right path. – kdtong Aug 12 '16 at 17:41
0

You can force TeamCity to built on a specific agent without disabling all other connected agents.

Here's how:

Goto Build Configuration Settings

Next Agent Requirements

Now you have to set an Explicit Requirement for a particular agent:

Parameter Name: system.agent.name

Condition: equals

Value: YOUR_SPECIFIC_AGENT_NAME

Also you can try this:

Browse through: TeamCity --> Administration --> Agents --> Select an Agent --> Compatible Configurations tab, then Current run configuration policy then Run assigned configurations only and click on + Assign configurations and finish.

Please let me know if this helps.

Thank you.

Animesh Patra
  • 2,454
  • 1
  • 10
  • 14
  • But unfortunately this will require some micro-management, we want to avoid. We have 10 agents where 8-9 might be usable for the build configurations of a specific project. So we will have to go through 23 build configurations times 12 projects and set this agent.name requirement for each of them. Not so good. And even worse, we will get more agents and continuously change the configuration of all agents. – Tonny Madsen Aug 03 '16 at 09:29
-1

I could not find a way to parameterize the value with %...% substitutions, but I found a workaround. It's not ideal, but it works for my small use case.

Use case: I am creating build configurations from a template and need each build configuration to only run on a single, specific machine. I wanted to do teamcity.agent.name equals %buildAgentName% in the template to have TeamCity prompt me to fill in the parameter when I create the build configuration from template.

Solution: Instead of using a parameter I just put in a string that would not match any agent names, e.g. teamcity.agent.name equals replaceThisWithActualAgentName in the template. I am not prompted for the parameter but this prevents the build configuration from accidentally running on the wrong machine until I override the agent requirement.

I am not sure if this solves your use case but I am posting it here in case it is helpful for someone else.

Andrew Kolbus
  • 1