Можно ли получить значения пользовательских возможностей агента сборки TFS на этапах сборки?

Определяемые пользователем возможности — это только метаданные. Но вы можете установить глобальную переменную среды (например, NUGET) и указать для нее путь к nuget.exe, когда вы перезапустите агент, среда всей машины будет обнаружена как возможность, и вы сможете ее использовать.

Если вы пишете пользовательскую задачу, вы также можете добавить nuget.exe к задаче, которая будет загружена исполняющему агенту.

ОБНОВЛЕНИЕ: я сделал из этого общедоступное расширение.

ОБНОВЛЕНИЕ: это работает в Azure DevOps 2019.

В TFS 2018u1 работает следующее:

Import-Module "Microsoft.TeamFoundation.DistributedTask.Task.Common"
Import-Module "Microsoft.TeamFoundation.DistributedTask.Task.Internal"
Add-Type -Assembly "Microsoft.TeamFoundation.DistributedTask.WebApi"

$VSS = Get-VssConnection -TaskContext $distributedTaskContext
$AgentCli = $VSS.GetClient([Microsoft.TeamFoundation.DistributedTask.WebApi.TaskAgentHttpClient])

$AgentConfig = Get-Content "$Env:AGENT_HOMEDIRECTORY\.agent" -Raw | ConvertFrom-Json
$Agent = $AgentCli.GetAgentAsync($AgentConfig.PoolId, $Env:AGENT_ID, $TRUE, $FALSE, $NULL, $NULL, [System.Threading.CancellationToken]::None).GetAwaiter().GetResult()

if($Agent.UserCapabilities.MyCapability)
{
    Write-Host "Got the capability!";
} 

Длинная строка аргументов по умолчанию, оканчивающаяся на CancellationToken::None, предназначена для совместимости с Powershell 4. PS4 не поддерживает значения по умолчанию для параметров метода, типизированного значением, PS5 поддерживает.

Этот фрагмент делает что-то очень сомнительное — он зависит от местоположения и структуры файла конфигурации агента. Это хрупко. Проблема в том, что для метода GetAgentAsync требуются как идентификатор пула, так и идентификатор агента, а первый не отображается в переменных среды. Чуть менее хакерским подходом будет проверка всех пулов и поиск нужного по идентификатору агента:

$Pools = $AgentCli.GetAgentPoolsAsync($NULL, $NULL, $NULL, $NULL, $NULL, [System.Threading.CancellationToken]::None).GetAwaiter().GetResult()
$Demands = New-Object 'System.Collections.Generic.List[string]'
foreach($Pool in $Pools)
{
    $Agent = $AgentCli.GetAgentsAsync($Pool.ID, $Env:AGENT_NAME, $TRUE, $FALSE, $NULL, $Demands, $NULL, [System.Threading.CancellationToken]::None).Result
    if($Agent -and $Agent.Id -eq $Env:AGENT_ID)
    {
        Break
    }
}

Это зависит от другой недокументированной детали реализации, а именно от того, что идентификаторы агентов уникальны в глобальном масштабе. Кажется, это держится вплоть до TFS 2018, но кто знает.

Когда вы используете $distributedTaskContext, задача подключается обратно к TFS с искусственным идентификатором пользователя, «Службой сборки коллекции проектов» (а не с учетной записью службы агента). В каждой коллекции есть один такой пользователь, они разные. Чтобы разрешить задачам, запущенным в выпусках в коллекции, запрашивать у агента возможности пользователя, необходимо предоставить роль читателя соответствующему пулу (пулам) (или всем пулам) учетной записи пользователя с именем «Служба сборки коллекции проектов (< em>TheCollectionName)" из этой коллекции.

Также похоже, что некоторые действия также предоставляют неявную роль читателя в пуле удостоверению задачи.

Кроме того, вы можете создать VssConnection с нуля с учетными данными Windows и предоставить учетным записям агента роль читателя в пуле (пулах).