I have set up a multi-agent job for an Azure Release Pipeline. There are two agents in the agent pool. The job needs to be executed by every agent in the agent pool.
The settings shown in the above schedule two agent jobs whenever a release is triggered. If both agents are idle while the deployment starts, everything works as expected and both agents execute the job. But, as soon as one agent is busy at that time the behavior becomes unexpected and both jobs are executed by the same agent consecutively.
How can I ensure that every agent of the agent pool is executing the defined agent job?
This is as designed. If one agent pool has two agents A and B, while A is busy, the build job will running with B. So in pool, if some agents are busy, the pipeline will running with other free and available agent.
The precondition of Parallel job is that you must has enough agents free and available. That's why as soon as one agent is busy at that time the behavior becomes unexpected.
Related
I have the following question on how jobs are scheduled onto agents in an Agent pool.
AzDO Job Scheduling on Agents
This pertains to HOW the AzDO pipeline decides to pick which of the agents from the pool to run jobs.
The expectation is that jobs will be evenly distributed across the agents in the pool. However, we are noticing that only one of the agents is repeatedly the target of job executions, and this is skewing up the agent usage and rest of the agents are idling, while jobs are waiting.
I examined if there are any demand/capabilities placed on the agents and there are none.
Questions: -
What is the algorithm or job scheduling policy used to pick the
agents? Is there any default stickiness once the job starts landing
in an agent, meaning once an agent is selected from a pool then
subsequent jobs get sticky to the same agent?
Why is only a single agent out of multiple agents in a pool getting used, while rest of agents are idling.
ADO does not pick an agent. The agents "ask" ADO if there is new work for them: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops&tabs=browser#communication-with-azure-pipelines
You mention "jobs". I'm not sure if you mean the technical term of an ADO job. If so: Jobs belong to a stage. An entire stage will always be executed on the same agents. Subsequent stages might be running on different agents.
I assume you are not using "Capabilities"?! Otherwise that might explain the behavior that you are seeing.
My pipeline triggers on resources, schedule and merges. Sometimes these can happen almost at the same time and many pipeline runs can be created. I've noticed that the jobs that run don't always belong to the same run.
Example
one pipeline A includes 2 jobs j.1 and j.2
a resource triggers A.1 and starts j.1
another resource triggers A.2 also and queues j.1.
A.1 finishes a job and instead of starting j.2 it is A.2 j.1 that starts.
How do I lock the run so that A.1 j.1 and j.2 runs to completion before A.2 starts?
On the agent, the queue is for the job-level not pipeline-level. So, normally the agent will be allocate to the higher priority jobs in the pipelines regardless of whether the jobs are in the same pipeline run.
Currently, we have not method or settings to manager the sort of the queued jobs.
I have a release pipeline composed of several stages
The tfs server have only one worker.
When i start a release, the worker run stages randomly.
The problem is : if someone else start another pipeline, sometimes the worker take the other pipeline before getting back to the next stage.
Is there a way to lock the worker on the entire release pipeline ?
When running a pipeline, a job is the unit of scale. This means each job can potentially run on a different agent.
Each job runs on an agent. A job represents an execution boundary of a set of steps. All of the steps run together on the same agent.
Next to that,
A stage is a logical boundary in the pipeline. It can be used to mark separation of concerns (for example, Build, QA, and production).
More information: Azure Pipelines - Key concepts.
You should also have a look at the Pipeline run sequence. It clearly explains how the entire pipeline-process works.
Whenever Azure Pipelines needs to run a job, it will ask the pool for an agent.
If the availability of the agent is the issue, you might want to add more agents to the pool. If needed, you can even run multiple agents on the same machine.
Although multiple agents can be installed per machine, we strongly suggest to only install one agent per machine. Installing two or more agents may adversely affect performance and the result of your pipelines.
After reading the very short official documents about the azure pipeline agent, I am getting very confused.
What exactly is an azure pipeline agent?
What is an agent job?
What's the relationship between agent and VM?
What's the relationship between agent job and VM? For each agent， one VM will be temporally assigned to it and will be back to the pool after the agent job finished?
If 2 different agent jobs run by 2 agents need the same running environment and the VM is agent job dependent. How should I retain the first agent job's running environment after it's finished running? Recreated again?
If each agent needs a VM, why create this concept? why not just directly use the VM or container?
Pipeline agent is machine where your build is performed. An agent is installable software that runs one job at a time.
Agent job is a set of steps which is recognized as execution boundary. Each job runs on an agent. All of the steps run together on the same agent.
From that perspective you can distinguish two kind of jobs - the onces installed on VM and onces instaled on container.
Agent job runs on agent which can be installed on VM. VM's are not assigned. Agents are assigned. There is agent pool, not VM pool.
I don't understand this one. Agents after finishing their job are going back to pool.
You may have more agents on on VM for instance one agents is installed on VM and few others as containers.
Please take a look here. You will find explanation for these concepts.
I am using Azure devops as a service. I have a build with multiple agents. This is partly to organize the build tasks into logical groups and also because one the Agents is used with a Multi-Configuration/Multiplier to perform a set of tasks n times. Each agent has a dependency on the one before it.
It appears the pipeline queues all the agents. The problem is when I cancel a build, the current agent may be canceled -- but the next agent queued continues.
For example, the Multiplier agent queues n instances. Canceling the build only cancels the current agent - the next one in the queue then starts up.
How do I get the build to cancel in it's entirety when you "Cancel" the build ?