Dear Sir/Madam
We are currently working with Continua 1.7.0.80-Beta. We have several physical machines of different performance level and setup which we would like to use as Agents. Not every machine/Agent has the same setup due to compiler license issues (node locked licenses). Some are limited to only process basic tasks (Nunit), others are enabled to compile code using a dedicated license.
We would like to prioritize the agent arbitration. Basic tasks/stages which can be executed on every machine/Agent should be delegated to such limited machines/Agents so that Agents with node locked licenses are free for tasks/stages which need such license.
How can such arbitration be configured?
Thanks for your help and best regards,
Philippe
Hi Phillipe,
Agents are chosen according to their compatibility with the actions in the stage using property collectors. Each stage action specifies one or more property collectors which can look for various properties such as an executable or registry key on each agent. If the defined property is not found then the agent is incompatible and will not be chosen to run the stage. You can define you own custom property collector for each action.
You can also set up agent requirements. These can be defined in the Stage Options dialog which is accessible by clicking on each stage icon on the Stage editor. You can add expressions which test the value of different agent properties. You could, for example, restrict a stage to a specific agent hostname or match a build branch to an agent property. Note that you can add custom properties to each agent or custom property collectors on the Administration pages and these can be checked or compared in the agent requirements.
You can also define a set of agent conditions on the Agents page in the Administration area which that must all be true before a build can run on a particular agent. You could, for example, use this to tie an agent to a specific project or configuration.
There is some further information in the documentation, although I am now noticing that some of this is incomplete and will need some fleshing out.
Hi Dave,
Thanks a lot for your fast reply. I am familiar with “Edit Stage Options -> Agent Requirements” however it cannot resolve my particular problem. I don’t want to restrict a task to a particular agent, I just want to prioritize tasks run by agents (make sure that the agent with the licence first handles tasks which need a licence, afterwards all agents should finish the overall job as fast as possible).
Maybe a small example can help:
- assume we have two agents (Agent1, Agent2): Agent1 can compile and run unit-tests, Agent2 can only run unit-tests
- assume we have a project with 3 configurations (C1, C2 and C3) and every configuration has two stages (A, B): first Compiling and then Testing
(for simplicity, Compiling and Testing take the same amount of time)
Currently the build sequence is somehow like this:
- Agent1: C1A (Agent1 compiles first configuration)
- Agent1: C1B (Agent1 tests first configuration), Agent2 would also be available however, Continua does not see a reason to switch configuration to Agent2
- Agent1: C2A (Agent1 compiles second configuration)
- Agent1: C2B (Agent1 tests second configuration), Agent2 would also be available however, Continua does not see a reason to switch configuration to Agent2
- Agent1: C3A (Agent1 compiles third configuration)
- Agent1: C3B (Agent1 tests third configuration)
Agent2 cannot assist Agent1 in the overall process because we cannot force the task to switch the agent.
We could restrict compiling to Agent1 and testing to Agent2, however the machine running Agent2 is also used for other tasks (not related to nightly builds) and therefore not every night available for nightly builds.
We would like to have following build sequence:
- Agent1: C1A (Agent1 compiles first configuration)
- Agent1: C2A (Agent1 compiles second configuration), Agent2: C1B (Agent2 tests first configuration)
- Agent1: C3A (Agent1 compiles third configuration), Agent2: C2B (Agent2 tests second configuration)
- Agent1: C3B (Agent1 tests third configuration)
However when Agent2 is not available everythingl should be done by Agent1.
Can you let me know how this can be achieved?
Best regards,
Philippe
Hi Philippe,
Continua should currently work as you wish. When selecting an agent it gets a list of compatible agents which have not reached the concurrent build limit and selects the one with the lowest number of running stages. I’ve just tested this here and it does still seem to work as described.
How many valid licenses are installed on the server? You need to have licenses to run on remote agents as well as to run builds concurrently. Can you also check that all agents are online, authorised and compatible with your stages on the Administration -> Agents and Agent Compatibility Matrix pages?
Try setting the concurrent stage limit to 1 for each agent and running two builds. If the second build waits for the first build stage to finish running on Agent 1 then this suggests that Agent 2 is either offline, unauthorised, unlicensed or incompatible.
If everything seems ok, can you send some screenshots of these pages and a diagnostics report (download from the link at the top of the event log page) to support@finalbuilder.com?
Hi Dave,
Thanks for your reply. Unfortunately Continua CI does not choose the agents according to our idea by default. The case I was describing in my last post was just a simplified example with two agents and configurations of two stages.
In reality we have six agents distributed over four workstations. Three workstations are equipped with specific USB-license-dongles for embedded system compilers and Nunit-Test-Frameworks. Each of these three workstations has a concurrent Continua-build-license. It is not possible to run more than one instance of the embedded compiler. The fourth machine has no licenses for embedded compilers however it can run three concurrent Continua-build-licenses hence Nunit-Tests.
We have a lot of different configurations of different number of stages. However the common thing is that the first stage of every configuration is always the compilation with the embedded system compiler.
So every configuration must start on one of the first three workstations with the compiler afterwards all subsequent stages can be executed on every machine. To speed up the overall build process the configuration should switch to the fourth machine (with 3 concurrent agents) when compilation is done. The fourth machine can only handle subsequent stages of configurations (Nunit-Test) but it can handle them fast and in parallel.
Nunit-Test should only be executed on one of the first three workstations if there are no more pending configurations with open first stages which need the embedded compiler. If all first stages of all configurations are done we do not care anymore which Nunit-Test runs on which agent. We just want to use all six concurrent licenses as efficient as possible.
Currently I cannot understand how such behavior can be forced using property collectors or agent requirements. I would need to form an agent requirement which depends on pending tasks/stages.
If you think it should be possible I would be glad if you could guide me through the process of setting up such conditions.
Best regards,
Philippe
Hi Philippe,
Do you actually have three agent services installed on workstation four? I’ll assume that you mean that you wish to allocate three build licenses to a single agent on that workstation 4?
Agent A on workstation 1: one embedded compiler (Build Stage can only run on this)
Agent B on workstation 2: one embedded compiler (Build Stage can only run on this)
Agent C on workstation 3: one embedded compiler (Build Stage can only run on this)
Agent D on workstation 4: can run any stage but is fast (possibly limited to 3 concurrent builds?)
Here’s my interpretation of your requirements:
Requirement 1: Agents A, B and C can only run one Build stage at a time
There is currently no way to specify that an agent can only run one Build stage, but we can specify that each agent can only run one stage (any stage) at a time by setting the concurrent stage limit to 1.
We do plan the implement the concept of agent (and server) resources. This will allow you to add a resource to an agent with a quota e.g. embeddedCompiler (quota = 1). You will then be able to specify that the stage should acquire this resource (if the quota has not been reached) in the agent requirements.
Requirement 2: : The Build stage can run only on agent A, B or C only (not D).
When we implement agent resources the stage will only run on agents with these resources, meanwhile you can satisfy this requirement with using property collectors or agent requirements
Solution 1: Ensure that the action for running the compiler uses a property collector which points to an executable which exists only on Agents A, B and C
Solution 2: Add a custom text property collector. Set this to the same value for agents A, B, C. Check for this property value in the agent requirements.
Solution 3: Add an agent requirement to each Build stage: $Agent.Hostname$ Is Not Equal To "Agent D Hostname"
Requirement 3: The NUnit-Test stage can run on any agent but only on agents A, B and C if there is no Build Stage waiting in the queue.
This cannot currently be done. It could possibly be done if we implement server-level resources which can be acquired at the start of the build. Perhaps a server resource with a count of the number of stages requiring the compiler. The NUnit-Test stage could than compare this server resource with the number of agent compiler resources acquired. I have added an item to our to-do list to investigate how we could implement this.
Note that we also plan to implement Agent Weightings allowing you to specify the relative importance of agent properties for selecting an agent for a stage. You will, for example, be able to use this to specify that the NUnit-Test Stage should prefer Agent D.
Hi Dave,
Thanks for your reply. Your interpretation is correct. We were able to satisfy Requirement 1 & 2. We are now looking for a solution to fulfil Requirement 3. Requirement 3 is not critical just as waste of resources on workstation 4. Therefore we are looking forward to hearing from you about the Agent Weighting mechanismn.
Thanks a lot for your help! Best regards,
Philippe