Есть ли способ заставить NuGet восстановить последнюю версию пакета во время выполнения конвейера? - PullRequest
Новая
       78

Есть ли способ заставить NuGet восстановить последнюю версию пакета во время выполнения конвейера?

0 голосов
/ 10 июля 2020

Мы используем внутренний канал NuGet в нашей среде Azure DevOps для размещения множества различных пакетов, которые используются во многих различных проектах. Я хотел бы настроить конвейер так, чтобы всякий раз, когда упоминается внутренний пакет, он всегда разрешался до последней версии. Все внутренние ссылки настроены с помощью подстановочных знаков в теге PackageReference файла .vbproj, например: 

<PackageReference Include="MyPackageName" Version="*" />

И команда восстановления в файле YAML настроена следующим образом: 

- task: NuGetCommand@2
    condition: and(succeeded(), eq(variables['ModifiedProject'], 'true'))
    displayName: 'NuGet restore'
    inputs:
      command: 'restore'
      restoreSolution: '$(ModifiedProject.Directory)/$(ModifiedProject.Solution)'
      feedsToUse: 'select'
      vstsFeed: '[guid]/[guid]'
      noCache: true

Проекты собираются успешно, но они все равно используют самую старую версию пакета вместо восстановления самой новой версии. Есть ли способ заставить задачу восстановления по умолчанию использовать самую новую версию пакета?

Ответы [ 2 ]

0 голосов
/ 17 июля 2020

В итоге я нашел способ решения этой проблемы с помощью Azure DevOps REST API . Моя цель состояла в том, чтобы запустить конвейер через следующие c шаги:

  1. После успешного завершения всех этапов сборки pu sh новой версии пакета в ленте артефактов.
  2. Используйте REST API, чтобы удалить старую версию пакета из списка, оставив доступной только самую новую версию.
  3. Из-за использования плавающих версий в тегах PackageReference любые проекты, которые зависят от этих пакетов, будут автоматически вытаскивать самую новую версию, когда они построены в своих соответствующих конвейерах. в корзину. В случае критического изменения, обнаруженного после sh, мы всегда можем восстановить предыдущую версию фида. Учитывая, что этот процесс используется исключительно для наших более чем 50 внутренних пакетов с собственными процессами тестирования, он определенно кажется безопасным путем к go и гораздо более эффективным, чем любой другой вариант, который я могу найти. Однако я не думаю, что отмечу это как окончательный ответ на вопрос, потому что он все еще кажется немного взломанным, и я бы предпочел, чтобы существовала законная возможность принудительно установить новейшие версии в Azure NuGetCommand@2 задача.

    Код

    Как уже упоминалось, я использовал хорошо документированный REST API Azure для этих функций, особенно в областях, управляющих артефакты . Хотя есть страница, посвященная удалению пакета из канала NuGet, я не смог заставить их спецификацию работать. В итоге я проверил вызовы, сделанные из пользовательского интерфейса, и скопировал их, все еще используя свой собственный токен для аутентификации. Этот метод выполняет «обрезку» истории, в которой я нуждался: 

    public void TrimPackageFeed(string feedName, string packageName)
{
    var packageVersions = GetPackageVersions(feedName, packageName);
    var deprecated = packageVersions.Where(x => !x.IsLatest && !x.IsDeleted)?.ToList();

    if (deprecated != null && deprecated.Any())
    {
        foreach (var version in deprecated)
        {
            var url = $"{version.Links.Feed.Value.Replace("feeds.dev.azure.com", "pkgs.dev.azure.com")}/nuget/packagesBatch";
            var payload = new AzurePackagePayload
            {
                Data = null,
                Operation = 2,
                Packages = new List<AzurePackagePayloadItem>
                {
                    new AzurePackagePayloadItem
                    {
                        ID = packageName,
                        Version = version.Version
                    }
                }
            };
            ApiRequest(url, Method.POST, null, JsonConvert.SerializeObject(payload));
        }
    }
}

    Я построил это как приложение командной строки. NET Core 3.1, опубликованное как автономный исполняемый файл в нашем репозитории сборки. Я использовал C#, потому что он мне наиболее знаком, но я уверен, что его можно написать на любом языке (возможно, даже на PowerShell). Затем я добавил следующую задачу в конец моего определения конвейера YAML: 

    - task: CmdLine@2
  condition: and(succeeded(), eq(variables['ModifiedProject'], 'true'))
  displayName: 'Trim package feed'
  inputs:
    script: |
      AzureApiClient -action trim-package-feed -feed FeedNameHere -package $(ModifiedProject.AssemblyName)
    workingDirectory: 'Azure\AzureApiClient\Output'
    failOnStderr: true

    Пакет помещается в канал, затем имя сборки передается моему клиенту API, который обрезает исторические версии и оставляет для восстановления доступна только новая версия.

0 голосов
/ 10 июля 2020

Если вы используете собственный агент для запуска конвейера, вы можете попытаться очистить локальный кеш nuget, удалить все пакеты nuget в глобальном кеше nuget под C:\Users\xxx\.nuget\packages или использовать очистить кеш nuget .

Если пакет, который нужно использовать, просто вставлен в канал, вам нужно немного подождать. При заполнении пакетов в ленте должна быть задержка.

Кроме того, вы можете попробовать использовать задачу do tnet restore, чтобы узнать, возникает ли эта проблема по-прежнему. Вот билет с аналогичной проблемой, к которой вы можете обратиться.

...