I'm building a packer image for Azure Devops based on Ubuntu 20.04 for self-hosting. But I can't figure out how I should be adding capabilities. I've installed things like Java and Android SDK and set environment variables for their paths. I can see these when I run printenv but they aren't picked up by the agent. I've stopped & re-started the service, the only way I can get capabilities is by adding them to the .env in the folder where the devops agent is installed and stopping / restarted. How should this work ?
Related
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.
If I am using a self-hosted deployment agent for my azure devops Ci\CD pipeline , and the pipeline is regarding to deploy Azure databricks notebook and also to build Azure sql database project and deploy dacpac ,
what component is required to be installed in that self-host agent ?
what component is required to be installed in that self-host agent ?
Prerequisites:
• Windows 7, 8.1, or 10 (if using a client OS)
• Windows 2008 R2 SP1 or higher (if using a server OS)
• PowerShell 3.0 or higher
• .NET Framework 4.6.2 or higher
Note - the minimum required .NET version for build agents is 4.6.2 or
higher. If you're building from a Subversion repo, you must install
the Subversion client on the machine.
You should run agent setup manually the first time.
Prepare permissions
Information security for self-hosted agents
Authenticate with a personal access token (PAT)
Confirm the user has permission
Download and configure the agent
Before you install a self-hosted agent you might want to see if a
Microsoft-hosted agent pool will work for you. In many cases this is
the simplest way to get going.
For more information refer - https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops&tabs=browser#install
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/
Microsoft's own documentation provides the links to the images used for various operating systems, on top of which Microsoft-hosted agents get created.
For Windows Server 2019, the link shows bash as one of the tools included, and it also mentions WSL1 (Windows Subsystem for Linux v1) as installed. And it works just as expected, with Bash tasks running just fine inside Azure DevOps pipelines.
We're currently in the process of setting up our own self-hosted Windows agents, and we're looking for this capability as well. But to my knowledge, having Linux tools such as bash working on Windows requires 1) WSL installed and 2) a Linux distribution installed per a specific user. The procedure for deploying on Windows Server is here.
WSL doesn't currently have multiple-user support (GitHub issue here) and trying to run Linux tools as LOCAL SYSTEM presents challenges of their own. So in this context, how does the image used by the Microsoft-hosted Azure DevOps agents allow them to seamlessly run bash?
I heard about Cygwin, and know that it can provide similar functionality, but for now I'm trying to get bash configured similar to how it's done on Microsoft's own hosted agents.
As of this time, however, I think it is not supported running bash in Azure DevOps self-hosted Windows agent.
The Bash task runs on the agent as the user "NT Authority \ Network Service". However, we cannot install Linux distribution for this user. It will show that the user haven't logged in.
But for Microsoft, its virtual machines should have a specific user from whom bash starts rather than the default NT Authority \ Network Service.
Currently when I run the Publish symbols task on the Ubuntu hosted agent I get the following error "The current operating system is not capable of running this task. That typically means the task was written for Windows only. For example, written for Windows Desktop PowerShell."
I have run this task successfully on a Windows Agent but what I have seen it doesn't work on Linux. The only thing that I have seen that could work on Linux is SourceLink but that doesn't work with Azure DevOps Artifacts yet.
Looking around I'm not able to see any way to publish symbols to Azure DevOps artifacts on a Linux agent? Has anybody else encountered this issue and were you able to get around it?