Teamcity - Is there a way to select the build config after it gets assigned to an agent?

0
votes

Is there a way to change the build config after it gets assigned to an agent from the queue? The workflow I'm hoping for:

change in vcs root -> queue up 'run tests' -> if Agent A, run 'run tests', if Agent B, run 'run tests in Docker'

More context: I have an instance of teamcity which I maintain, but do not have admin access to. This means I can't install what I need to on the server. We have certain installs on certain build agent servers. I created different versions of our 'run tests' build config, such that it will run on all the available agents. This is a fairly simple difference: the test suite runs regularly with the one build config (on default agent) & runs in a docker container on the others (on the other two build servers). Not all servers have docker installed.

To be clear, these build configs are not sequential to each other - they are the same build config, but different versions. I don't want both jobs listening for vcs changes - as this will kick off both build configs. I simply would like to put a condition in front of the run but after the queue, however the data flow seems to be one way (queue up job, then assign to agent).

1
continuous-integrationteamcity
As I understood, you would like to have a single build configuration runnable on the default agent, as well as on the agents that you have control over. A couple of questions: 1) Does your 'run tests in Docker' build step add an implicit agent requirement that can't be fulfilled by the default agent? 2) Do you have write access to the default agent's buildAgent.properties file? – tolache
@tolache I have the agent requirements configured such that the docker job will run on the servers with docker installed and vice versa. I do have write access to the prop file yes. It's not a matter of making sure the right job runs on the right server - that I have covered with agent requirements. Rather I'm trying to configure a custom trigger effectively, such that the correct version of 'run tests' is queued up, after the agent it will run on has been determined. – Phil

1 Answers

1
votes

You should be able to achieve what you need using the conditional build steps, but I would not recommend that too much because the solution would be a bit hacky:

  1. Add both build steps, 'run tests' and 'run tests in Docker', to your build configuration.
  2. Add a condition to 'run tests' step: Execute step if teamcity.agent.name equals <dockerless-agent-name>.
  3. Add another condition to 'run tests in Docker' step: Execute step if teamcity.agent.name does not equal <dockerless-agent-name>.
  4. Here's the hacky part. Add the implicit agent requirements imposed by the docker step into the buildAgent.properties file of your dockerless agent. Example: If you use docker wrapper in your 'run tests in Docker' step, it will impose the docker.server.version exists agent requirement on the build configuration. In that case, add the line docker.server.version=whaterver to dockerless agent's buildAgent.properties.

TeamCity will think that the agent that doesn't have docker can run the 'run tests in Docker' step, and will be able to assign the build to that agent. But if that happens, the 'run tests' step will be executed instead of 'run tests in Docker'. That's about it.

Additionally, if the feature of ignoring implicit agent requirements if a condition is used in a build step gets implemented, you would be able to achieve the goal without hacking it through buildAgent.properties.