Is it possible to clone or copy an Azure Pipeline Hosted Agent for use as a Self-Hosted Agent?
I'd like to reuse one of the Hosted Agents simply to enable me recreate and reuse all of its
capabilities, saving me the headache. Is this possible and if so I'd really appreciate some help.
Thanks
This is not possible, but you can try to reuse what is already available here https://github.com/actions/virtual-environments
This repository contains the source used to create the virtual environments for GitHub Actions hosted runners, as well as the VM images of Microsoft-hosted agents used for Azure Pipelines. To file bug reports, or request that tools be added/updated, please open an issue using the appropriate template. To build a VM machine from this repo's source, see the instructions.
So you can use the same scripts which are used to create Microsoft Hosted agents.
There is no such build-in feature.
Azure DevOps provides free hosted agents that have a predefined set
of tools installed and configured for building and releasing your
apps.
There is another option where you set up and manage your own agents.
This can be done by simply downloading the agent package, and run it
either on your local machine or any other computing platform even on
Docker container. It also gives you more freedom to install specific
dependencies for your build and release.
If you want to build your own agent during the pipeline. I would suggest you use Docker container to handle the process.
Microsoft has already created pre-configured container images on Docker Hub for everybody to use. But they’re Linux based and don’t contain any additional applications and/or packages so you’d probably still need to add those every time you run your build.
This repository contains images for the Visual Studio Team Services
(VSTS) agent that runs tasks as part of a build or release.
VSTS agent images are tagged according to the base OS, an optional
Team Foundation Server (TFS) version, and tools that are installed.
When used with VSTS, the agent version is automatically determined and
downloaded at container startup based on the account to which the
agent is connecting.
More detail step, you could refer this article: Build your own Azure DevOps agents with pipelines
Related
To promote CI/CD for Analysis Services tabular models (SSAS, Azure AS or Power BI datasets), I always recommend people to use Tabular Editor with Azure DevOps. One popular feature of Tabular Editor's CLI, is that it can perform a schema check, in which Tabular Editor connects to the data source defined within the tabular model, in order to validate the partition queries against the actual columns specified in the model metadata.
Microsoft recommends the use of the MSOLEDBSQL provider (1,2) for SQL Server-based data sources. Unfortunately, this provider is not available on Microsoft-hosted build agents in Azure Pipelines (neither vs2017-win2016 nor windows-2019).
Unfortunately, the installer for MSOLEDBSQL requires admin permission, so I don't think that we can install the driver as part of our pipeline.
One workaround is to use Tabular Editor's scripting functionality to temporarily change the data source to use for example the SQLNCLI provider when performing the schema check. However, it feels like the missing MSOLEDBSQL driver on the build agents is an oversight on Microsoft's part, especially considering that they're recommending the use of this driver for production purposes.
Is there any way we can have the MSOLEDBSQL driver available on a Microsoft-hosted Windows-based build agent?
Is there any way we can have the MSOLEDBSQL driver available on a
Microsoft-hosted Windows-based build agent?
Virtual Environments repo contains the source used to create the virtual environments for GitHub Actions hosted runners, as well as the VM images of Microsoft-hosted agents used for Azure Pipelines.To file bug reports, or request that tools be added/updated, please open an issue using the appropriate template.
So I think you can open a Tool Request here with the given template, then the team there would consider and check your feedback.
In addition: As temporary workaround you can consider installing one self-hosted agent in your local machine, so that you can run the pipeline with local environment. (With more control to install dependent software needed for your build and deployment)
Currently, we use Azure DevOps for build and release pipelines but host repos on GitHub. We would like to make use of GitHub actions to replace this and bring everything into one location.
We use a self hosted Azure DevOps release pipeline which allows us to download and configure our app on our own server.
However the article here implies that GitHub Actions self hosted runners utilise a sandbox.
Could they be used without a sandbox to copy our program to a path on our server and then run the program?
There is nothing in that article that implies anything about self-hosted runners being sandboxed from an internal network perspective.
Self-hosted runners offer more control of hardware, operating system,
and software tools than GitHub-hosted runners provide. With
self-hosted runners, you can choose to create a custom hardware
configuration with more processing power or memory to run larger jobs,
install software available on your local network, and choose an
operating system not offered by GitHub-hosted runners. Self-hosted
runners can be physical, virtual, container, on-premises, or in a
cloud.
GitHub Actions runs under the nt authority\network service account.
According to https://learn.microsoft.com/en-us/windows/win32/services/networkservice-account:
It has minimum privileges on the local computer and acts as the computer on the network.
Therefore the "machine's runner sandbox" referred to in the article is likely referencing this account's inability to perform any privileged tasks.
I am migrating XAML Builds to Azure Devops. Goal is to remove the dedicated Build Staging server to cut costs.
Following is the process:
1) Build ASP.NET Web Application.
2) Copy configs, assemblies, WebPackage from Build output to various folders in UNC share which will be later picked up by a Release Pipeline Job.
Since Microsoft Hosted Agents dont allow usage of UNC share, I wanted to use Self Hosted Agent.
Question:
Can I use a Self Hosted Agent without the necessity of a dedicated server to hold the Build Output in Image or Container which can then be copied to the UNC Share? I am new to Devops and hence the articles on MS confused me if I need a dedicated server or not.
Tried to set up a Self Hosted Agent pool, but the steps suggest that I require a machine where the Self Hosted Agent need to be setup. If this is the case then it means I will be requiring a dedicated machine like in XAML process. Am I blabbering? Please excuse if yes :-)
Expected Result: Run a Build Pipeline with Self Hosted Agents on Cloud without the requirement of a Dedicated Server.
UNC Shares or not, the "self hosted agent" is an agent you install on your own server, there can be multiple reasons for that, for example accessing an sql server for testing that is on your own local network, to perform tests against during builds.
If you are trying to reduce costs, a self-hosted agent can be benefitial if you already have server hardware it can run on. If not, you might aswell just use a hosted build agent, anything build on that can be published directly azure devops or other places though various build tasks.
...Since Microsoft Hosted Agents dont allow usage of UNC share...
This is not a problem, there is no reason for you to use UNC shares.
You don't need to access UNC shares to store artifacts for later consumption; use the Publish Artifacts build activity. That will store your build outputs internally and make them available to downstream releases.
I am working for a WPF application, and recently I have migrated TFS to Azure DevOps and I am successfully able to create build artifacts as well, unfortunately, I could not create executable from the artifacts as Azure DevOps does not support InstallShield Package creation with it, now I decided to move the build artifacts to my local build server,again my company law doesn't allow to access my server from outside network, what should do to create executable.
The Build Agent needs to be able to connect to Azure DevOps. It's enough for it to be able to make an outgoing connection over https (443). The agent can be configured to connect through a web proxy server.
What alternatives do you have:
Use the hosted agent and install InstallShield as part of the build process. This will be slow, but it is doable. You'll need to execute this step as part of every build that tries to create the InstallShield package and requires you to do a head-less installation of InstallShield (given that they are the kings of Installers, I suppose this is doable).
Use a private agent in Azure. You can spin up any IaaS server on Azure, install Visual Studio, InstallShield and the Azure DevOps Agent on it and use it as a build server. There is a set of standard images file available which you can use as a basis.
It doesn't look like this is possible but is there a way to use VSTS Continuous Delivery and deploy to a server outside Azure?
Sure. VSTS Continuous Delivery can deploy to anything that can run the VSTS agent or anything that can be targetted from a VSTS agent. Basically you have two options:
Let the VSTS (hosted) agent communicate directly to your deployment target. Out of the box tasks can use MsDeploy or WinRM. There are also tasks for Octopus Deploy, AWS and other systems available through the Marketplace. Powershell has options to connect directly to other systems and you can use many different protocols from a powershell script.
Install the VSTS agent on your target machine (or network). The VSTS agent can be downloaded and installed onto the target server. That way you have full local access to the target machine and can simply copy the files to the target folder straight from the Release Management artefacts. By installing a VSTS agent in you local network, you can use the options listed under 1 to bypass firewalls that might be blocking the hosted agent.