Support for macOS X Mojave (10.14) is here! If you're using the 'Hosted macOS' agent pool today, your pipelines are running on Mojave. If you'd like to remain on High Sierra (10.13), then select the 'Hosted macOS High Sierra' agent pool for your pipelines.
If your pipelines are in Azure Pipelines, then you've got a convenient option to run your jobs using a Microsoft-hosted agent. With Microsoft-hosted agents, maintenance and upgrades are taken care of for you. Each time you run a pipeline, you get a fresh virtual machine. The virtual machine is discarded after one use. Microsoft-hosted agents can run jobs directly on the VM or in a container.
For many teams this is the simplest way to run your jobs. You can try it first and see if it works for your build or deployment. If not, you can use a self-hosted agent.
You can try a Microsoft-hosted agent for no charge. If your job fails, the issues will be reported in the logs.
Use a Microsoft-hosted agent
Azure Pipelines provides a Microsoft-hosted agent pool named Azure Pipelines that offers 7 virtual machine images to choose from, each including a broad range of tools and software:
The Azure Pipelines hosted pool replaces the previous hosted pools that had names that mapped to the corresponding images. Any jobs you had in the previous hosted pools are automatically redirected to the correct image in the new Azure Pipelines hosted pool. In some circumstances, you may still see the old pool names, but behind the scenes the hosted jobs are run using the Azure Pipelines pool. For more information about this update, see the Single hosted pool release notes from the July 1 2019 - Sprint 154 release notes.
|Image||Classic Editor Agent Specification||YAML VM Image Label||Included Software|
|Windows Server 2019 with Visual Studio 2019||windows-2019||
|Windows Server 2016 with Visual Studio 2017||vs2017-win2016||
|Windows Server 2012 R2 with Visual Studio 2015||vs2015-win2012r2||
|Windows Server Core 1803 (for running Windows containers)||win1803||
|macOS X Mojave 10.14||macOS-10.14||
|macOS X High Sierra 10.13||macOS-10.13||
Pipelines will default to the Microsoft-hosted agent pool. You simply need to specify which virtual machine image you want to use.
jobs: - job: Linux pool: vmImage: 'ubuntu-latest' steps: - script: echo hello from Linux - job: macOS pool: vmImage: 'macOS-latest' steps: - script: echo hello from macOS - job: Windows pool: vmImage: 'windows-latest' steps: - script: echo hello from Windows
Notes on choosing "Hosted macOS"
This option affects where your data is stored. Learn more.
To disable the Microsoft-hosted macOS agent pool for all projects, disable the
Hosted Agent checkbox under Admin settings > Agent pools > Hosted macOS and Admin settings > Agent pools > Hosted macOS High Sierra.
To disable the Microsoft-hosted macOS agent pool for a specific project, disable the
Hosted Agent checkbox under Project settings > Agent pools > Hosted macOS and Admin settings > Agent pools > Hosted macOS High Sierra.
You can manually select from tool versions on macOS images. See below.
Capabilities and limitations
- Have the above software. You can also add software during your build or release using tool installer tasks.
- Provide at least 10 GB of storage for your source and build outputs.
- Provide a free tier:
- Public project: 10 free Microsoft-hosted parallel jobs that can run for up to 360 minutes (6 hours) each time, with no overall time limit per month. Contact us to get your free tier limits increased.
- Private project: One free parallel job that can run for up to 60 minutes each time, until you've used 1,800 minutes (30 hours) per month. You can pay for additional capacity per parallel job. Paid parallel jobs remove the monthly time limit and allow you to run each job for up to 360 minutes (6 hours). Buy Microsoft-hosted parallel jobs.
- Run on Microsoft Azure general purpose virtual machines Standard_DS2_v2
- Run as an administrator on Windows and a passwordless sudo user on Linux
- (Linux only) Run steps in a cgroup that offers 6 GB of physical memory and 13 GB of total memory
Microsoft-hosted agents do not offer:
- The ability to sign in.
- The ability to drop artifacts to a UNC file share.
- The ability to run XAML builds.
- Potential performance advantages that you might get by using self-hosted agents which might start and run builds faster. Learn more
If Microsoft-hosted agents don't meet your needs, then you can deploy your own self-hosted agents.
Avoid hard-coded references
When you use a Microsoft-hosted agent, always use variables to refer to the build environment and agent resources. For example, don't hard-code the drive letter or folder that contains the repository. The precise layout of the hosted agents is subject to change without warning.
Agent IP ranges
In some setups, you may need to know the range of IP addresses where agents are deployed. For instance, if you need to grant the hosted agents access through a firewall, you may wish to restrict that access by IP address. Because Azure DevOps uses the Azure global network, IP ranges vary over time. We publish a weekly JSON file listing IP ranges for Azure datacenters, broken out by region. This file is published every Wednesday (US Pacific time) with new planned IP ranges. The new IP ranges become effective the following Monday. We recommend that you check back frequently to ensure you keep an up-to-date list. If agent jobs begin to fail, a key first troubleshooting step is to make sure your configuration matches the latest list of IP addresses.
Your hosted agents run in the same Azure geography as your organization. Each geography contains one or more regions, and while your agent may run in the same region as your organization, it is not guaranteed to do so. To obtain the complete list of possible IP ranges for your agent, you must use the IP ranges from all of the regions that are contained in your geography. For example, if your organization is located in the United States geography, you must use the IP ranges for all of the regions in that geography.
To determine your geography, navigate to
https://dev.azure.com/<your_organization>/_settings/organizationOverview, get your region, and find the associated geography from the Azure geography table. Once you have identified your geography, use the IP ranges from the weekly file for all regions in that geography.
Due to capacity restrictions, some organizations in the Brazil South or West Europe regions may occasionally see their hosted agents located outside their expected geography. In these cases, additional IP ranges must be included for regions in the capacity fallback geography.
If your organization is in the Brazil South region, your capacity fallback geography is United States.
If your organization is in the West Europe region, the capacity fallback geography is France.
Our Mac IP ranges are not included in the Azure IPs above, though we are investigating options to publish these in the future.
Can I use service tags instead?
Currently, Service Tags is not something you can use for your hosted agents. If you're trying to grant hosted agents access to your resources, you'll need to follow the IP range allow listing method.
Q & A
I can't select a Microsoft-hosted agent and I can't queue my build or deployment. How do I fix this?
By default, all project contributors in an organization have access to the Microsoft-hosted agents. But, your organization administrator may limit the access of Microsoft-hosted agents to select users or projects. Ask the owner of your Azure DevOps organization to grant you permission to use a Microsoft-hosted agent. See agent pool security.
I need more agents. What can I do?
All Azure DevOps organizations are provided with several free parallel jobs for open source projects, and one free parallel job and limited minutes each month for private projects. If you need more minutes, or need to run additional builds or releases in parallel, then you can buy more parallel jobs for private projects.
I'm looking for the Microsoft-hosted XAML build controller. Where did it go?
The Microsoft-hosted XAML build controller is no longer supported. If you have an organization in which you still need to run XAML builds, you should set up a self-hosted build server and a self-hosted build controller.
We strongly recommend that you migrate your XAML builds to new builds.
How can I manually select versions of tools on the Hosted macOS agent?
To manually select a Xamarin SDK version to use on the Hosted macOS agent, before your Xamarin build task, execute this command line as part of your build, replacing the Mono version number 5.4.1 as needed (also replacing '.' characters with underscores: '_'). Choose the Mono version that is associated with the Xamarin SDK version that you need.
/bin/bash -c "sudo $AGENT_HOMEDIRECTORY/scripts/select-xamarin-sdk.sh 5_4_1"
Mono versions associated with Xamarin SDK versions on the Hosted macOS agent can be found here.
Note that this command does not select the Mono version beyond the Xamarin SDK. To manually select a Mono version, see instructions below.
In case you are using a non-default version of Xcode for building your Xamarin.iOS or Xamarin.Mac apps, you should additionally execute this command line:
/bin/bash -c "echo '##vso[task.setvariable variable=MD_APPLE_SDK_ROOT;]'$(xcodeRoot);sudo xcode-select --switch $(xcodeRoot)/Contents/Developer"
Xcode versions on the Hosted macOS agent pool can be found here.
If you use the Xcode task included with Azure Pipelines and TFS, you can select a version of Xcode in that task's properties. Otherwise, to manually set the Xcode version to use on the Hosted macOS agent pool, before your
xcodebuild build task, execute this command line as part of your build, replacing the Xcode version number 8.3.3 as needed:
/bin/bash -c "sudo xcode-select -s /Applications/Xcode_8.3.3.app/Contents/Developer"
Xcode versions on the Hosted macOS agent pool can be found here.
Note that this command does not work for Xamarin apps. To manually select a Xcode version for building Xamarin apps, see instructions above.
To manually select a Mono version to use on the Hosted macOS agent pool, before your Mono build task, execute this script in each job of your build, replacing the Mono version number 5.4.1 as needed:
SYMLINK=5_4_1 MONOPREFIX=/Library/Frameworks/Mono.framework/Versions/$SYMLINK echo "##vso[task.setvariable variable=DYLD_FALLBACK_LIBRARY_PATH;]$MONOPREFIX/lib:/lib:/usr/lib:$DYLD_LIBRARY_FALLBACK_PATH" echo "##vso[task.setvariable variable=PKG_CONFIG_PATH;]$MONOPREFIX/lib/pkgconfig:$MONOPREFIX/share/pkgconfig:$PKG_CONFIG_PATH" echo "##vso[task.setvariable variable=PATH;]$MONOPREFIX/bin:$PATH"
.NET Core 2.2.105 is default on VM images but Mono version 6.0 or greater requires .NET Core 2.2.300+. If you use the Mono 6.0 or greater, you will have to override .NET Core version using .NET Core Tool Installer task.
The VM images contain prebuilt Boost libraries with their headers in the directory designated by
BOOST_ROOT environment variable. In order to include the Boost headers, the path
$BOOST_ROOT/include should be added to the search paths.
Example of g++ invocation with Boost libraries:
g++ -I "$BOOST_ROOT/include" ...