### Install SSH Key Task Example

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/install-ssh-key-v0.md

This example demonstrates the basic usage of the InstallSSHKey task to install a single SSH key. It shows how to specify the known hosts entry, the public key using a secret variable, and the private key from a secure file.

```yaml
steps:
- task: InstallSSHKey@0
  displayName: 'Install an SSH key'
  inputs:
    knownHostsEntry: 'SHA256:1Hyr55tsxGifESBMc0s+2NtutnR/4+LOkVwrOGrIp8U johndoe@contoso'
    sshPublicKey: '$(myPubKey)'
    sshKeySecureFile: 'id_rsa'
```

--------------------------------

### Install Specific Helm Version

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-installer-v1.md

Example demonstrating the installation of a specific Helm version using an explicit version string.

```yaml
- task: HelmInstaller@1
  displayName: Helm installer
  inputs:
    helmVersionToInstall: 2.14.1
```

--------------------------------

### Install Latest Helm Version

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-installer-v1.md

Example of installing the latest available version of the Helm binary on the agent.

```yaml
- task: HelmInstaller@1
  displayName: Helm installer
  inputs: 
    helmVersionToInstall: latest
```

--------------------------------

### Example: Install Latest Kubelogin

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/kubelogin-installer-v0.md

Demonstrates how to use the KubeloginInstaller@0 task to install the latest version of kubelogin. The 'kubeloginVersion' input can be omitted as 'latest' is the default.

```yaml
- task: KubeloginInstaller@0

# Other tasks that depend on kubelogin
- task: HelmDeploy@0
  # task inputs...
```

--------------------------------

### NodeTaskRunnerInstaller@0 Remarks and Example

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/node-task-runner-installer-v0.md

This section provides remarks on using the NodeTaskRunnerInstaller@0 task, particularly for scenarios involving older Node.js versions. It includes a practical YAML example demonstrating how to install the Node 6 runner just-in-time for an older task.

```yaml
steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6
```

--------------------------------

### Example: Install Specific Kubelogin Version

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/kubelogin-installer-v0.md

Shows how to explicitly specify a version for the kubelogin installation using the 'kubeloginVersion' input in the KubeloginInstaller@0 task.

```yaml
- task: KubeloginInstaller@0
  inputs:
    kubeloginVersion: 'latest' # or a specific version like '0.0.30'
```

--------------------------------

### HelmDeploy with 'install' command

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-deploy-v0.md

This example demonstrates deploying a Helm chart using the 'install' command with the HelmDeploy task. It specifies the chart type and path.

```YAML
- task: HelmDeploy@0
  displayName: Helm install
  inputs:
    azureSubscriptionEndpoint: $(azureSubscriptionEndpoint)
    azureResourceGroup: $(azureResourceGroup)
    kubernetesCluster: $(kubernetesCluster)
    command: install
    chartType: FilePath
    chartPath: Application/charts/sampleapp
```

--------------------------------

### DockerInstaller@0 Example Usage

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/docker-installer-v0.md

An example of how to use the DockerInstaller@0 task in an Azure Pipeline YAML file to install a specific Docker version.

```yaml
- task: DockerInstaller@0
  displayName: Docker Installer
  inputs:
    dockerVersion: 17.09.0-ce
    releaseType: stable
```

--------------------------------

### Go Task Example

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/go-v0.md

An example Azure Pipelines YAML snippet demonstrating the use of the Go@0 task for various Go operations like getting dependencies, building, and archiving artifacts.

```yaml
variables:
  GOBIN:  '$(GOPATH)/bin' # Go binaries path
  GOROOT: '/usr/local/go1.11' # Go installation path
  GOPATH: '$(system.defaultWorkingDirectory)/gopath' # Go workspace path
  modulePath: '$(GOPATH)/src/github.com/$(build.repository.name)' # Path to the module's code

steps:
- task: GoTool@0
  displayName: 'Use Go 1.10'

- task: Go@0
  displayName: 'go get'
  inputs:
    arguments: '-d'

- task: Go@0
  displayName: 'go build'
  inputs:
    command: build
    arguments: '-o "$(System.TeamProject).exe"'

- task: ArchiveFiles@2
  displayName: 'Archive files'
  inputs:
    rootFolderOrFile: '$(Build.Repository.LocalPath)'
    includeRootFolder: False

- task: PublishBuildArtifacts@1
  displayName: 'Publish artifact'
  condition: succeededOrFailed()
```

--------------------------------

### FuncToolsInstaller@0 Task Inputs

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/func-tools-installer-v0.md

Details the inputs for the FuncToolsInstaller@0 task, specifically the 'version' input which allows specifying the Azure Functions Core Tools version to install. It provides examples of valid version formats and a link to the releases page.

```APIDOC
FuncToolsInstaller@0:
  inputs:
    version:
      type: string
      defaultValue: 'latest'
      description: |
        Specifies the version of Azure Functions Core Tools to install. For example:

        - `2.7.1575`
        - `v2.7.1575`
        - `latest`

        For a list of versions, see [Azure Functions Core Tools releases](https://github.com/Azure/azure-functions-core-tools/releases).
```

--------------------------------

### Install Provisioning Profile Task Requirements

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/install-apple-provisioning-profile-v1.md

This documentation outlines the requirements for using the Install Provisioning Profile task, including pipeline types, agent compatibility, necessary demands (like 'xcode'), command restrictions, and settable variables.

```APIDOC
InstallAppleProvisioningProfile@1:
  Description: Installs an Apple provisioning profile.
  Requirements:
    Pipeline types: YAML, Classic build, Classic release
    Runs on: Agent, DeploymentGroup
    Demands: xcode
    Capabilities: None for subsequent tasks.
    Command restrictions: restricted (for Azure Pipelines 2022+), Any (for Azure Pipelines 2020.1 and earlier).
    Settable variables: provisioningProfileUuid, provisioningProfileName, APPLE_PROV_PROFILE_UUID (for Azure Pipelines 2022+), Any (for Azure Pipelines 2020.1 and earlier).
    Agent version: 2.182.1 or greater (for Azure Pipelines 2022+), 2.116.0 or greater (for Azure Pipelines 2020.1 and earlier).
    Task category: Utility
  Inputs:
    provisioningProfileLocation:
      Type: string
      Description: Location of the provisioning profile (secureFiles, sourceRepository, or path).
    contents:
      Type: string
      Description: The name of the provisioning profile file.
    installAsManaged:
      Type: boolean
      Description: Whether to install the profile as managed.
    signingCertificate:
      Type: string
      Description: The signing certificate to use.
    signingPassword:
      Type: string
      Description: The password for the signing certificate.
    provisioningProfileUuid:
      Type: string
      Description: The UUID of the provisioning profile.
    provisioningProfileName:
      Type: string
      Description: The name of the provisioning profile.
```

--------------------------------

### DotNetCoreInstaller@0 Task

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/dotnet-core-installer-v0.md

This YAML snippet demonstrates the usage of the DotNetCoreInstaller@0 task to install a .NET Core SDK. It specifies the package type as 'sdk' and a version, for example, '1.0.4'. The task is used to acquire a specific version of the .NET Core SDK from the internet or local cache and add it to the PATH.

```yaml
# .NET Core SDK/runtime installer v0
# Acquire a specific version of the .NET Core SDK from the internet or local cache and add it to the PATH.
- task: DotNetCoreInstaller@0
  inputs:
    packageType: 'sdk' # 'runtime' | 'sdk'. Required. Package to install. Default: sdk.
    version: '1.0.4' # string. Required. Version. Default: 1.0.4.

```

--------------------------------

### VSTest Demand and Setup

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/vstest-v3.md

Explains the 'vstest' demand and how to satisfy it. The demand can be met by having Visual Studio installed on the agent or by using the Visual Studio Test Platform Installer task.

```yaml
pool:
  demands: vstest
```

--------------------------------

### Package and Sign Helm Chart in Azure Pipelines

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-deploy-v0.md

An Azure DevOps pipeline example that downloads a secure file (private key), installs Helm, initializes the Helm client, and packages a Helm chart with signing.

```YAML
pool:
  name: Hosted Ubuntu 1604

variables:
  # The below variable should be secure
  HelmKeyPassphrase: contoso@123
  keyName: contoso contoso@microsoft.com
  azureSubscriptionEndpoint: contoso
  azureResourceGroup: contoso
  kubernetesCluster: contoso

steps:
- task: DownloadSecureFile@1
  displayName: Download Secure file
  inputs:
    secureFile: privatekey.gpg
  name: privateKeyRing

- task: HelmInstaller@0
  displayName: Install Helm 2.12.0
  inputs:
    helmVersion: 2.12.0

- task: HelmDeploy@0
  displayName: helm init
  inputs:
    azureSubscriptionEndpoint: $(azureSubscriptionEndpoint)
    azureResourceGroup: $(azureResourceGroup)
    kubernetesCluster: $(kubernetesCluster)
    command: init
    arguments: --client-only

- task: HelmDeploy@0
  displayName: helm package
  inputs:
    command: package
    chartPath: Application/charts/sampleapp
    arguments: --sign --key "$(keyName)" --keyring $(privateKeyRing.secureFilePath)
  env:
    HelmKeyPassphrase: $(HelmKeyPassphrase)
```

--------------------------------

### Visual Studio Test Platform Installer Requirements

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/visual-studio-test-platform-installer-v1.md

Details the requirements for running the Visual Studio Test Platform Installer task, including pipeline types, agent compatibility, and capabilities satisfied by the task.

```APIDOC
Visual Studio Test Platform Installer Task Requirements:

Pipeline types:
  - YAML
  - Classic build
  - Classic release

Runs on:
  - Agent
  - DeploymentGroup

Demands:
  - None

Capabilities:
  - Running this task satisfies the following demands for any subsequent tasks in the same job: VsTest

Command restrictions:
  - Any

Settable variables:
  - Any

Agent version:
  - 2.144.0 or greater (for Azure Pipelines 2022.1+)
  - 2.103.0 or greater (for Azure Pipelines <= 2022)

Task category:
  - Tool
```

--------------------------------

### Web Deploy Installation

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/azure-rm-web-app-deployment-v5.md

Instructions for installing Web Deploy on an agent, specifying the required version and installation path.

```powershell
# Download and install Web Deploy 3.6
$webDeployUrl = "https://download.microsoft.com/download/6/7/A/67AE40C9-54A1-44C7-8A8A-8A853A371A47/WebDeploy_3.6_x64_en-US.msi"
Start-Process msiexec.exe -ArgumentList "/i `"$webDeployUrl`" /quiet" -Wait

# Verify installation path
$webDeployPath = "C:/Program Files (x86)/IIS/Microsoft Web Deploy V3/msdeploy.exe"
```

--------------------------------

### Install Kubectl using KubectlInstaller@0

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/kubectl-installer-v0.md

This task installs a specified version of the kubectl binary on the agent machine. It can install the latest version or a specific semantic version string.

```yaml
- task: KubectlInstaller@0
  displayName: Kubectl installer
  inputs:
    kubectlVersion: latest
```

```yaml
- task: KubectlInstaller@0
  displayName: Kubectl installer
  inputs:
    kubectlVersion: 1.15.0
```

--------------------------------

### Helm Command Options

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-deploy-v0.md

Specifies the Helm command to execute. Supported commands include create, delete, expose, get, init, install, login, logout, ls, package, rollback, save, upgrade, and uninstall. The default command is 'ls'.

```APIDOC
`command` - Command
`string`. Required. Allowed values: `create`, `delete`, `expose`, `get`, `init`, `install`, `login`, `logout`, `ls`, `package`, `rollback`, `save`, `upgrade`, `uninstall`. Default value: `ls`.
```

--------------------------------

### Visual Studio Test Platform Installer Task

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/visual-studio-test-platform-installer-v1.md

This task installs the Microsoft test platform from NuGet.org or a specified feed onto the agent. It satisfies the `vstest` demand, enabling the Visual Studio Test task to run without a full Visual Studio installation.

```yaml
steps:
- task: VisualStudioTestPlatformInstaller@1
  displayName: 'Install test platform'
```

--------------------------------

### Install Provisioning Profile Task Configuration

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/install-apple-provisioning-profile-v1.md

This snippet shows how to configure the Install Provisioning Profile task in an Azure Pipelines YAML file. It specifies the path to the provisioning profile and the service connection to use.

```yaml
steps:
- task: InstallAppleProvisioningProfile@1
  inputs:
    provisioningProfileLocation: 'secureFiles'
    contents: 'my-provisioning-profile.mobileprovision'
    installAsManaged: true
    signingCertificate: $(APPLE_CERTIFICATE_SIGNING_KEY)
    signingPassword: $(APPLE_CERTIFICATE_PASSWORD)
    provisioningProfileUuid: $(APPLE_PROV_PROFILE_UUID)
    provisioningProfileName: $(APPLE_PROV_PROFILE_NAME)
```

--------------------------------

### installationPath Input

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/dotnet-core-installer-v1.md

Specifies the directory where the .NET Core SDK/Runtime should be installed. Defaults to '$(Agent.ToolsDirectory)/dotnet'. Using $(Agent.ToolsDirectory) caches versions across pipelines, while $(Agent.TempDirectory) cleans them up after each pipeline.

```yaml
installationPath: string # Default: "$(Agent.ToolsDirectory)/dotnet"
```

--------------------------------

### installationPath Input

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/use-dotnet-v2.md

Specifies the path where the .NET Core SDK or runtime should be installed.

```APIDOC
installationPath: string
  Description: Path To Install .Net Core
```

--------------------------------

### Notation Install Command

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/notation-v0.md

Installs the Notation CLI by detecting the OS and architecture, downloading the appropriate binary from GitHub releases, verifying its checksum, and adding it to the system's PATH.

```yaml
steps:
- task: Notation.NotationCli@1
  displayName: 'Install Notation CLI'
  inputs:
    command: 'install'
```

--------------------------------

### InstallAppleProvisioningProfile@1 Task Output Variables

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/install-apple-provisioning-profile-v1.md

This section outlines the output variables provided by the InstallAppleProvisioningProfile@1 task. These variables can be consumed in downstream steps, jobs, and stages.

```APIDOC
InstallAppleProvisioningProfile@1:
  outputVariables:
    provisioningProfileUuid:
      description: 'The UUID property for the selected provisioning profile.'
    provisioningProfileName:
      description: 'The Name property for the selected provisioning profile.'
```

--------------------------------

### packageType Input

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/dotnet-core-installer-v1.md

Specifies whether to install only the Runtime or the full SDK for .NET Core. Allowed values are 'runtime' and 'sdk'. Defaults to 'sdk'.

```yaml
packageType: string # Required. Allowed values: runtime, sdk. Default: sdk
```

--------------------------------

### DotNetCoreInstaller@1 Task Syntax

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/dotnet-core-installer-v1.md

This YAML snippet shows the basic syntax for using the DotNetCoreInstaller@1 task in Azure Pipelines. It specifies the package type (sdk or runtime) and the exact version to install. Optional inputs like including preview versions or specifying an installation path are commented out.

```yaml
# .NET Core SDK/runtime installer v1
# Acquire a specific version of the .NET Core SDK from the internet or local cache and add it to the PATH.
- task: DotNetCoreInstaller@1
  inputs:
    packageType: 'sdk' # 'runtime' | 'sdk'. Required. Package to install. Default: sdk.
    version: '2.2.x' # string. Required. Version. Default: 2.2.x.
    #includePreviewVersions: false # boolean. Include Preview Versions. Default: false.
  # Advanced
    #installationPath: '$(Agent.ToolsDirectory)/dotnet' # string. Path To Install .Net Core. Default: $(Agent.ToolsDirectory)/dotnet.
    #performMultiLevelLookup: false # boolean. Perform Multi Level Lookup. Default: false.
```

--------------------------------

### Java Tool Installer Task Remarks

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/java-tool-installer-v1.md

Provides important remarks and configuration notes for the Java Tool Installer task, including macOS specific requirements and Azure RBAC setup for Azure Storage.

```markdown
## Remarks

Use this task to acquire a specific version of Java from a user-supplied Azure blob, a location in the source or on the agent, or the tools cache. The task also sets the `JAVA_HOME` environment variable.
Use this task to change the version of Java used in Java tasks.

> [!NOTE]
>
> To run the **Java Tool Installer** task on macOS, it is required for the user under which the agent is running to have permission to execute the **sudo** command without a password.
You can follow the next steps to enable this permission:

> 1) Run the *sudo visudo* command. The sudoers file opens for editing.
> 2) Go to the bottom of the file and add the following line: `user ALL=NOPASSWD: /usr/sbin/installer` (Replace user with the actual user alias).
> 3) Save and close the file.

### Configure Azure RBAC to access Azure storage

This version of the task uses an [Azure Resource Manager service connection](/azure/devops/pipelines/library/connect-to-azure) configured using workload identity federation and Azure RBAC to connect to Azure storage instead of storage account keys or shared access signatures (SAS). To connect to Azure storage from this task, you must assign the [Storage Blob Data Contributor](/azure/role-based-access-control/built-in-roles/storage#storage-blob-data-contributor) role on the storage account to the identity of the service connection configured for `azureResourceManagerEndpoint`. For more information, see [Assign an Azure role for access to blob data](/azure/storage/blobs/assign-azure-role-data-access) and [Steps to assign a role](/azure/role-based-access-control/role-assignments-steps).
```

--------------------------------

### Helm Initialization Options

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-deploy-v1.md

Configuration options for initializing Helm, including whether to use the canary Tiller image and if Tiller should be upgraded if already installed.

```APIDOC
init:
  # Use the canary Tiller image, the latest pre-release version of Tiller.
  useCanaryImage: boolean (optional, default: false)
  # Upgrade if Tiller is already installed.
  upgradeTiller: boolean (optional, default: true)
```

--------------------------------

### Download Secure File and Install Certificate (Linux)

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/download-secure-file-v1.md

Downloads a secure certificate file and installs it to a trusted certificate authority (CA) directory on Linux. It uses the DownloadSecureFile task to get the file and then a script to set permissions and create a symbolic link.

```yaml
- task: DownloadSecureFile@1
  name: caCertificate
  displayName: 'Download CA certificate'
  inputs:
    secureFile: 'myCACertificate.pem'

- script: |
    echo Installing $(caCertificate.secureFilePath) to the trusted CA directory...
    sudo chown root:root $(caCertificate.secureFilePath)
    sudo chmod a+r $(caCertificate.secureFilePath)
    sudo ln -s $(caCertificate.secureFilePath) /etc/ssl/certs/ 
```

--------------------------------

### Install Multiple SSH Keys with Advanced Configuration

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/install-ssh-key-v0.md

This example illustrates how to install multiple SSH keys in the same pipeline job using advanced configuration options. It shows how to set aliases, hostnames, and users for each key, enabling connections to different repositories via custom scripts. The task also handles restoring the SSH config file after the build.

```yaml
pool: <Some Agent Pool>

steps:
- task: InstallSSHKey@0
  inputs:
    knownHostsEntry: $(known_host)
    sshPublicKey: $(first_public_key)
    sshKeySecureFile: $(first_private_key)
    addEntryToConfig: true
    configHostAlias: <first-host-alias>
    configHostname: github.com
    configUser: git
  displayName: Install First Repo SSH Key

- task: InstallSSHKey@0
  inputs:
    knownHostsEntry: $(known_host)
    sshPublicKey: $(second_public_key)
    sshKeySecureFile: $(second_private_key)
    addEntryToConfig: true
    configHostAlias: <second-host-alias>
    configHostname: github.com
    configUser: git
  displayName: Install Second Repo SSH Key

- bash: git clone git@<first-host-alias>:<owner>/<first-repo>.git
  displayName: Clone First Repo

- bash: git clone git@<second-host-alias>:<owner>/<second-repo>.git
  displayName: Clone Second Repo
```

--------------------------------

### InstallAppleProvisioningProfile@1 Task Inputs

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/install-apple-provisioning-profile-v1.md

This section details the inputs for the InstallAppleProvisioningProfile@1 task. It covers the provisioning profile location, the profile itself (whether from Secure Files or Source Repository), and an option to remove the profile after the build.

```APIDOC
InstallAppleProvisioningProfile@1:
  inputs:
    provisioningProfileLocation:
      type: string
      required: true
      defaultValue: 'secureFiles'
      allowedValues: ['secureFiles', 'sourceRepository']
      description: 'Specifies the location of the provisioning profile to install. The provisioning profile can be uploaded to Secure Files, or stored in your source repository or a local path on the agent.'
    provProfileSecureFile:
      type: string
      required: true
      description: 'Specifies the provisioning profile that was uploaded to Secure Files to install on the macOS agent.'
    provProfileSourceRepository:
      type: string
      required: true
      description: 'Specifies the provisioning profile from the source repository or the local path to a provisioning profile on the macOS agent.'
    removeProfile:
      type: boolean
      defaultValue: true
      description: 'Specifies that the provisioning profile should be removed from the agent after the build or release is complete.'
```

--------------------------------

### PipAuthenticate Task Example

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/pip-authenticate-v1.md

This example demonstrates how to use the PipAuthenticate task to authenticate with an external Python distribution server. It requires a pre-configured pip service connection named 'pypitest'. After authentication, it installs a package named 'HelloTestPackage' using pip.

```YAML
- task: PipAuthenticate@1
  displayName: 'Pip Authenticate'
  inputs:
    pythonDownloadServiceConnections: pypitest

- script: |
    pip install HelloTestPackage
```

--------------------------------

### NuGetToolInstaller@0 Inputs

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/nuget-tool-installer-v0.md

This documentation details the inputs for the NuGetToolInstaller@0 task. It explains the 'versionSpec' input for specifying the NuGet version and the 'checkLatest' input for controlling the download behavior. It also provides guidance on version specifications and the implications of enabling 'checkLatest'.

```APIDOC
NuGetToolInstaller@0:
  inputs:
    versionSpec:
      type: string
      description: 'Version of NuGet.exe to install.'
      helpText: 'A version or version range that specifies the NuGet version to make available on the path. Use x as a wildcard. See the [list of available NuGet versions](https://dist.nuget.org/tools.json). If you want to match a pre-release version, the specification must contain a major, minor, patch, and pre-release version from the list above. If a version isn\'t specified, then one will be chosen automatically. Examples: `4.x`, `3.3.x`, `2.8.6`, `>=4.0.0-0`.'
    checkLatest:
      type: boolean
      defaultValue: false
      description: 'Always download the latest matching version.'
      helpText: 'When this boolean is set to `true`, the task always checks for and downloads the latest available version of `NuGet.exe` that satisfies the version spec. This option will also always incur download time, even if the selected version of NuGet is already cached. Enabling this option could cause unexpected build breaks when a new version of NuGet is released. If you\'re using [the Microsoft-hosted agents](/azure/devops/pipelines/agents/hosted), you should leave this set to false. Microsoft updates the Microsoft-hosted agents on a regular basis, but they\'re often slightly behind the latest version. Enabling this parameter could result in your build spending a lot of time updating to a newer minor version.'
```

--------------------------------

### VSTest Task Support for Multiple Target Frameworks

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/vstest-v2.md

Details the VSTest task's capability to run tests targeting multiple frameworks, starting from version 17.3. To utilize this, install a compatible VSTest version via the 'Visual Studio Test Platform Installer' and set 'vsTestVersion' to 'toolsInstaller'.

```APIDOC
VSTest Task - Multiple Target Frameworks:
  Support Status:
    - Supported starting from VSTest task version 17.3.
  Prior Limitations:
    - Previously not possible due to VSTest platform limitations.
  Usage:
    - To run tests for multiple target frameworks:
      1. Install a compatible VSTest version using the 'Visual Studio Test Platform Installer' task.
      2. Set the 'vsTestVersion' parameter to 'toolsInstaller'.
```

--------------------------------

### Network Share (UNC Path) Input

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/visual-studio-test-platform-installer-v1.md

Specifies the full UNC path to the Microsoft.TestPlatform.nupkg file when using a network share as the package source.

```APIDOC
netShare:
  type: string
  description: Specifies the full UNC path to the Microsoft.TestPlatform.nupkg file.
  required: true
  condition: "packageFeedSelector = netShare"
  details: The specified Microsoft.TestPlatform.nupkg version must be downloaded from NuGet and placed on a network share that the build/release agent can access.
```

--------------------------------

### version Input

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/dotnet-core-installer-v1.md

Specifies the version of .NET Core SDK or Runtime to install. Supports exact versions (e.g., '2.2.104'), latest in minor version (e.g., '2.2.x'), or latest in major version (e.g., '2.x'). Defaults to '2.2.x'.

```yaml
version: string # Required. Default: 2.2.x
```

--------------------------------

### Helm Chart Name

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-deploy-v0.md

The name of the chart to install or upgrade. This can be a URL or a chart name. For example, 'stable/mysql'. This parameter is required when `chartType` is 'Name'.

```APIDOC
`chartName` - Chart Name
`string`. Required when `chartType == Name`.
```

--------------------------------

### performMultiLevelLookup Input

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/dotnet-core-installer-v1.md

Configures .NET host processes to probe for a suitable shared framework using Multi-level Lookup. Applicable only to Windows-based agents. Defaults to 'false'.

```yaml
performMultiLevelLookup: boolean # Default: false
```

--------------------------------

### Xcode Developer Directory Path

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/xcode-v2.md

An optional parameter to specify the path to the Xcode Developer folder, used when multiple Xcode versions are installed. For example: '/Applications/Xcode 7.app/Contents/Developer'.

```APIDOC
xcodeDeveloperDir:
  type: string
  optional: true
  description: |-
    Optional. Specifies the path to the Xcode Developer folder if it's not the system default. For use when multiple versions of Xcode are installed on a system. For example: /Applications/Xcode 7.app/Contents/Developer.
```

--------------------------------

### HelmInstaller@0 Task Inputs

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-installer-v0.md

Details the input parameters for the HelmInstaller@0 task, including their types, requirements, default values, and descriptions.

```APIDOC
HelmInstaller@0:
  inputs:
    helmVersion:
      type: string
      required: true
      default: '2.14.1'
      description: 'Specifies the version of Helm to install.'
    checkLatestHelmVersion:
      type: boolean
      required: false
      default: true
      description: 'Checks for the latest version of Helm.'
    installKubeCtl:
      type: boolean
      required: false
      default: true
      description: 'Installs Kubectl.'
    kubectlVersion:
      type: string
      required: false
      default: '1.8.9'
      description: 'Specifies the version of Kubectl to install.'
      condition: 'installKubeCtl == true'
    checkLatestKubeCtl:
      type: boolean
      required: false
      default: true
      description: 'Checks for the latest version of Kubectl.'
      condition: 'installKubeCtl == true'
```

--------------------------------

### Azure App Service Manage Task

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/index.md

Manages Azure App Service by starting, stopping, restarting, swapping slots, deleting slots, installing site extensions, or enabling continuous monitoring.

```yaml
- task: AzureAppServiceManage@0
  inputs:
    # Inputs for Azure App Service Manage task version 0
    # ...
```

--------------------------------

### Run gulp.js

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/gulp-v1.md

This example demonstrates how to install npm packages and then run a gulp task using the gulp@1 task. It specifies the gulpfile.js to use and the path to the gulp.js executable.

```yml
- task: Npm@1
  inputs:
    command: 'install'

- task: gulp@1
  inputs:
    gulpfile: 'gulpfile.js'
    gulpjs: 'node_modules/gulp/bin/gulp.js'
```

--------------------------------

### Notation Setup

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/index.md

Azure Pipeline Task for setting up Notation CLI, signing, and verifying with Notation.

```yaml
Notation@0
```

--------------------------------

### Run Gulp.js Task

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/gulp-v0.md

Example of how to use the gulp@0 task in an Azure DevOps pipeline to execute gulp tasks. It first installs npm packages and then runs gulp.

```yaml
- task: Npm@1
  inputs:
    command: 'install'

- task: gulp@0
  inputs:
    gulpFile: 'gulpfile.js'
    gulpjs: 'node_modules/gulp/bin/gulp.js'
```

--------------------------------

### Helm Command Options

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-deploy-v1.md

Defines the primary Helm command to be executed. Supports various operations like create, delete, expose, get, install, package, push, and more.

```APIDOC
command:
  type: string
  required: true
  allowedValues: ["create", "delete", "expose", "get", "init", "install", "login", "logout", "ls", "push", "package", "rollback", "upgrade", "uninstall"]
  defaultValue: "ls"
  description: Select a helm command.
```

--------------------------------

### GoTool@0 Task Inputs

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/go-tool-v0.md

Details the inputs for the GoTool@0 task. The 'version' input is mandatory for specifying the Go version. 'goPath' and 'goBin' are optional inputs for custom environment variable configurations.

```APIDOC
GoTool@0:
  inputs:
    version: string. Required. Default: '1.10'.
      description: The Go version to download (if necessary) and use, for example '1.9.3'.
    goPath: string.
      description: A custom value for the GOPATH environment variable.
    goBin: string.
      description: A custom value for the GOBIN environment variable.
```

--------------------------------

### Azure App Service Manage Task

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/index.md

Manages Azure App Service instances, including starting, stopping, restarting, slot swapping, slot deletion, installing site extensions, and enabling continuous monitoring.

```yaml
steps:
- task: AzureAppServiceManage@0
  inputs:
    # Inputs for Azure App Service management
```

--------------------------------

### Enable Automatic CodeQL Installation

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/advanced-security-codeql-init-v1.md

Controls whether the task automatically checks for and installs the latest version of CodeQL if it's not correctly configured or outdated on the agent. This ensures the analysis uses an up-to-date CodeQL environment.

```yaml
enableAutomaticCodeQLInstall: boolean
```

--------------------------------

### GoTool@0 Task Configuration

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/go-tool-v0.md

Configures the GoTool@0 task to install a specific Go version. It accepts the Go version as a required input and optionally allows custom GOPATH and GOBIN environment variables.

```yaml
- task: GoTool@0
  inputs:
    version: '1.10' # string. Required. Version. Default: 1.10.
  # Advanced
    #goPath: # string. GOPATH. 
    #goBin: # string. GOBIN.
```

--------------------------------

### Startup Command for Linux Web Apps

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/azure-web-app-v1.md

Specifies the startup command for a Linux Web App. This is used to define how the application should be started after deployment. Examples include 'dotnet run' or 'dotnet filename.dll'.

```APIDOC
startUpCommand:
  type: string
  optional: true
  description: |-
    Specifies the start up command for a Linux Web App.
    For example: `dotnet run` or `dotnet filename.dll`.
```

--------------------------------

### Azure App Service Manage Task

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/index.md

Manages Azure App Service by starting, stopping, restarting, swapping slots, deleting slots, installing site extensions, or enabling continuous monitoring. Supports version 0 of the task.

```yaml
- task: AzureAppServiceManage@0
  inputs:
    # ... inputs for AzureAppServiceManage@0
```

--------------------------------

### Azure App Service Manage Task

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/index.md

Manages Azure App Service by starting, stopping, restarting, swapping slots, deleting slots, installing site extensions, or enabling continuous monitoring. Supports version 0 of the task.

```yaml
steps:
- task: AzureAppServiceManage@0
  inputs:
    # Inputs for Azure App Service management
```

--------------------------------

### HelmDeploy with 'upgrade' command

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/helm-deploy-v0.md

This example demonstrates upgrading a Helm release using the 'upgrade' command with the HelmDeploy task. It includes parameters for chart type, path, release name, and installation options.

```YAML
- task: HelmDeploy@0
  displayName: Helm upgrade
  inputs:
    azureSubscriptionEndpoint: $(azureSubscriptionEndpoint)
    azureResourceGroup: $(azureResourceGroup)
    kubernetesCluster: $(kubernetesCluster)
    command: upgrade
    chartType: filepath
    chartPath: $(Build.ArtifactStagingDirectory)/sampleapp-v0.2.0.tgz
    releaseName: azuredevopsdemo
    install: true
    waitForExecution: false
```

--------------------------------

### Package Feed Selector Input

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/visual-studio-test-platform-installer-v1.md

Defines how the task selects the package feed for the Visual Studio Test Platform. Options include official NuGet, custom feeds, or network paths.

```APIDOC
packageFeedSelector:
  type: string
  description: Specifies the feed where the task fetches the Visual Studio Test Platform NuGet package.
  required: true
  defaultValue: "nugetOrg"
  allowedValues:
    - "nugetOrg" (Official Nuget)
    - "customFeed" (Custom Feed)
    - "netShare" (Network path)
  details:
    nugetOrg: Acquires the test platform package from NuGet. Requires internet connectivity.
    customFeed: Acquires the test platform package from a custom feed or Azure DevOps/TFS feed.
    netShare: Installs the test platform from a network share. The package must be downloaded and placed on an accessible network share.
```

--------------------------------

### Xcode Developer Path

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/xcode-v3.md

An optional string that specifies the path to the Xcode Developer folder. This is useful when multiple Xcode versions are installed on a system and the default path needs to be overridden. Example: '/Applications/Xcode 7.app/Contents/Developer'.

```yaml
string.
```

--------------------------------

### Self-Hosted Agent Setup

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/msbuild-v1.md

Provides links to documentation for setting up self-hosted build agents on different operating systems. This is useful when needing to reproduce build errors locally or when using custom build environments.

```APIDOC
Self-Hosted Agent Setup:

- Self-hosted Windows agents: /azure/devops/pipelines/agents/v2-windows
- Self-hosted Linux agents: /azure/devops/pipelines/agents/v2-linux
- Self-hosted macOS agents: /azure/devops/pipelines/agents/v2-osx
```

--------------------------------

### CmdLine Task Examples

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/cmd-line-v2.md

Demonstrates practical usage of the CmdLine@2 task with various scenarios, including getting the date, listing directory contents, setting environment variables, and passing variables from YAML.

```yaml
steps:
- script: date /t
  displayName: Get the date
- script: dir
  workingDirectory: $(Agent.BuildDirectory)
  displayName: List contents of a folder
- script: |
    set MYVAR=foo
    set
  displayName: Set a variable and then display all
  env:
    aVarFromYaml: someValue
```

--------------------------------

### Azure App Service Manage Task

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/index.md

Manages Azure App Service instances, including starting, stopping, restarting, slot swapping, slot deletion, installing site extensions, and enabling continuous monitoring. This task supports version 0.

```yaml
- task: AzureAppServiceManage@0
  inputs:
    # Inputs for Azure App Service Manage
    ...
```

--------------------------------

### KubeloginInstaller@0 Task Inputs

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/kubelogin-installer-v0.md

Details the inputs for the KubeloginInstaller@0 task, including kubeloginVersion and gitHubConnection. kubeloginVersion specifies the version to install, defaulting to 'latest'. gitHubConnection is optional and used to prevent anonymous request limits to the GitHub API.

```yaml
inputs:
  kubeloginVersion: 'latest' # or a specific version like '0.0.30'
  gitHubConnection: # Optional GitHub connection
```

--------------------------------

### Universal Package Task Remarks and Examples

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/universal-packages-v0.md

Provides remarks on using the Universal Package task, including accessing feeds in different projects, and offers examples of pipeline configurations for packaging and publishing web applications.

```APIDOC
Remarks:
  Use this task to download, or package and publish Universal Packages.
  For pipelines in different projects, grant read/write access to the build service.

Examples:
  - Use the Pipelines task editor to generate YAML for the Universal Package task.
  - Example pipeline demonstrates fetching a tool, running a build, and publishing a compiled GatsbyJS PWA to a feed as a versioned Universal Package.
```

--------------------------------

### Test Results Files Input

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/grunt-v0.md

A required string input, used when `publishJUnitResults` is true, that specifies the path to the test results files. Wildcards are supported. For example, `**/TEST-*.xml` matches all XML files starting with `TEST-`.

```yaml
testResultsFiles: string
  # Required when publishJUnitResults = true. Default value: **/TEST-*.xml.
  # Specifies the test results files path. Wildcards can be used.
  # For example, "**/TEST-*.xml" for all XML file names that start with TEST-.
```

--------------------------------

### UseDotNet@2 Task Configuration

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/use-dotnet-v2.md

This snippet shows the basic structure and common input parameters for the UseDotNet@2 task in Azure Pipelines YAML. It demonstrates how to specify the package type, whether to use a global.json file, and the version of the .NET Core SDK to install. Optional advanced parameters like `vsVersion` and `installationPath` are also commented out.

```yaml
- task: UseDotNet@2
  inputs:
    packageType: 'sdk' # 'runtime' | 'sdk'. Package to install. Default: sdk.
    useGlobalJson: false # boolean. Optional. Use when packageType = sdk. Use global json. Default: false.
    workingDirectory: # string. Optional. Use when useGlobalJson = true. Working Directory. 
    version: # string. Optional. Use when useGlobalJson = false || packageType = runtime. Version. 
    includePreviewVersions: false # boolean. Optional. Use when useGlobalJson = false  || packageType = runtime. Include Preview Versions. Default: false.
  # Advanced
    vsVersion: # string. Compatible Visual Studio version. 
    installationPath: '$(Agent.ToolsDirectory)/dotnet' # string. Path To Install .Net Core. Default: $(Agent.ToolsDirectory)/dotnet.
    performMultiLevelLookup: false # boolean. Perform Multi Level Lookup. Default: false.
```

--------------------------------

### Publish Python Distribution to Official Python Registry (PyPI)

Source: https://github.com/microsoftdocs/azure-devops-yaml-schema/blob/main/task-reference/twine-authenticate-v1.md

This example shows how to use the TwineAuthenticate task to publish a Python distribution to the official Python registry (PyPI). It involves setting up a twine service connection, installing packages, building the distribution, authenticating, and uploading.

```YAML
# Install python distributions like wheel, twine etc
- script: |
    pip install wheel
    pip install twine

# Build the python distribution from source
- script: |
    python setup.py bdist_wheel

- task: TwineAuthenticate@1
  displayName: Twine Authenticate
  inputs:
    pythonUploadServiceConnection: pypitest # Name of the Python package upload service connection

- script: |
    python -m twine upload -r "pypitest" --config-file $(PYPIRC_PATH) dist/*.whl # Use -r to pass the repository name, and --config-file to point to the .pypirc path set by the TwineAuthenticate task
  displayName: Upload package with Twine
```