We have an on-premises Azure DevOps, currently version 2019 Update 1. Last night I upgraded to 2019 Update 1.2, and initially everything appeared to be fine. However I noticed that builds weren't starting because I could see that the agents were disabled/offline in Collection Settings -> Agent Pools.
We have two agents - the "default" (v2.153.1) installed when we first installed DevOps 2019, and a second agent that I installed myself (v2.210.1). I checked that both agents' services were running in Services.msc, but otherwise had no idea what else to do.
It was getting late so I ended up restoring the server snapshot so it was back up and running for today. I'll need to attempt the upgrade again soon though. Assuming I encounter this issue again, what do I have to do to get the agents working?
Related
I have an Azure DevOps agent pool configured to use a scale set, I also have an orchestration pipeline that triggers dozens of builds that will run on the agents provisioned by the scale set.
When builds are queued the scale set starts to provision new VMs as expected (albeit a bit slowly) and eventually the new VMs appear in the pool settings displaying having Agent version 2.165.2, however they will stay idle and not run any of the builds until they upgrade to a later version of the agent, i.e. 2.213.2.
Sometimes this upgrade takes less than a minute but in same cases it can take 15/20 mins or more, so I end up having a build queue waiting for agents that are already available but not taking any new builds until their agent version is upgraded, and during all this I am paying MS for the privilege of running idle VMs.
Is there a way for the VMs to be provisioned with the latest agent version without having to wait for this to be done as a follow up step?
It is recommended that you upgrade these agents to the latest version first at an available time before using them.
Turns out that the behaviour we were seeing was due to us unknowingly having an older version of the agent installed on the base image, we have now updated the VM with the latest version and the scale-set behaves more responsively.
When visiting my build agent on Azure, I get a warning that I must migrate away from Windows Server 2016 base image. I have updated the base image to the recommended version using the link provided in the warning message: How do I migrate my Windows Server 2016 container groups to Windows Server 2019 images?
The warning is still appearing in Azure Portal even though I have updated the version of the image. How can I verify that my build agent is running on Windows Server 2019 base image? This is a self-hosted agent so I'm not able to see it in DevOps -> AgentPool -> Azure Pipeline "Agent specifications"
I suppose that you could run a command line task with "systeminfo" to echo the agent information.
By the way, you could also run this command with your local CMD directly.
I've installed the latest VS Build Tools (2022), but my on-prem build agent isn't picking up the VisualStudio-related capabilities. I've been under the impression that we no longer need to install the full application in order to get these capabilities.
An example from this blog post:
I've added all workloads to my offline layout, and I've included them in my installation.
I know this is possible, because earlier I accidentally included Python and VS 2019 Build Tools in my Node.js installation configuration. The VS-related capabilities were found by the agent then.
But I'm trying to get 2022, so I uninstalled 2019.
How can I get the 2022 VS-related capabilities to be installed and detected by my build agent, without installing the full Visual Studio product?
You need to upgrade the agent to a recent enough version. You can download the agent from the azure-pipelines-agent repository's releases page. Or manually specify the capabilities.
You may need to set a special environment flag on the agent to prevent it from automatically being downgraded to whatever version shipped with your version if Azure DevOps Server or Team Foundation Server.
And then you'll also need to install the latest version of the vsbuild/msbuild and vstest tasks
Required agent version
You will need to install the most recent agent from the azure-pipelines-agent repository for it to auto-detect Visual Studio 2022, or alternatively add the capabilities to the agent manually.
You may need to force Azure DevOps Server to not downgrade back to its preferred agent version. You can do so by setting the following environment variable at the system level on your server before launching the agent:
AZP_AGENT_DOWNGRADE_DISABLED=true
These tricks will work for most tasks in the azure-pipelines-tasks repository, as long as it doesn't depend on a UI extension or service connection type that isn't available in your version of Azure DevOps Server.
https://jessehouwing.net/adding-visual-studio-2022-to-azure-devops-server-2020/
Background:
We are using the VSTS to build and Octopus integration to deploy our product. The Octopus step is configured as follows,
Issue
Today VSTS Build was throwing following error,
No supported agent found in pool Default. All agents in this pool are
using a version that is deprecated. Migrate to the latest 2.x version
of agent. For more information, see
https://go.microsoft.com/fwlink/?linkid=851067
As a result, the Agent was updated to the latest version,
After the update the octopus step stopped working with following error,
Then issue seems to be the environment variables are not replaced in the step.
I would like to know if there is a work around to fix this issue.
First, there is 2.* version available, so you can delete the old one and add the new one.
Secondly, use $(Build.BuildNumber) instead in Package Version input box, also for Output path: $(Build.ArtifactStagingDirectory).
We have a setup with MS Team Services where we have some local build agents. Recently we had some issues with errors about a not found system.io.compression. At the same time we could use hosted agents, but want to have the local running again. On one machine we managed to install a new agent that worked, but on another we get an error about system.io.compression when we try to install the agent. I'm not sure why this is suddenly an issue, maybe som gac mess up or other thing we need to clean up. the machines running the agents all have the latest Visual Studio 2017 installed