Buforuj pakiety NuGet

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Buforowanie potoków pomaga skrócić czas kompilacji, przechowując zależności do ponownego użycia w przyszłych uruchomieniach. Z tego artykułu dowiesz się, jak używać zadania Cache do buforowania i przywracania pakietów NuGet.

Wymagania wstępne

Blokowanie zależności

Przed skonfigurowaniem zadania pamięci podręcznej należy zablokować zależności projektu i wygenerować plik package.lock.json. Unikatowy klucz cache jest tworzony na podstawie skrótu zawartości tego pliku blokującego, w celu zapewnienia spójności w kompilacjach.

Aby zablokować zależności projektu, dodaj właściwość RestorePackagesWithLockFile do pliku csproj i ustaw ją na wartość true. Po uruchomieniu nuget restoreprogram generuje plik packages.lock.json w katalogu głównym projektu. Upewnij się, że dodajesz plik packages.lock.json do swojego kodu źródłowego.

<PropertyGroup>
  <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>

Buforuj pakiety NuGet

Aby buforować pakiety NuGet, zdefiniuj zmienną potoku wskazującą lokalizację pakietów na agencie, na którym działa potok.

W poniższym przykładzie zawartość packages.lock.json jest hashowana, aby wygenerować dynamiczny klucz pamięci podręcznej. Gwarantuje to, że za każdym razem, gdy plik ulegnie zmianie, zostanie utworzony nowy klucz pamięci podręcznej.

variables:
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages

- task: Cache@2
  displayName: Cache v2 task 
  inputs:
    key: 'nuget | "$(Agent.OS)" | **/packages.lock.json,!**/bin/**,!**/obj/**'
    restoreKeys: |
       nuget | "$(Agent.OS)"
       nuget
    path: '$(NUGET_PACKAGES)'
    cacheHitVar: 'CACHE_RESTORED'

Przywracanie pamięci podręcznej

Następujące zadanie zostanie uruchomione tylko wtedy, gdy zmienna CACHE_RESTORED jest false. Oznacza to, że jeśli wystąpi trafienie w pamięci podręcznej (pakiety są już dostępne w pamięci podręcznej), krok przywracania zostanie pominięty, co pozwala zaoszczędzić czas i zasoby. Jeśli pamięć podręczna nie zostanie znaleziona, polecenie przywracania zostanie uruchomione w celu pobrania niezbędnych zależności.

- task: NuGetCommand@2
  condition: ne(variables.CACHE_RESTORED, true)
  inputs:
    command: 'restore'
    restoreSolution: '**/*.sln'

Obsługa błędów "nie znaleziono project.assets.json"

Jeśli wystąpi błąd "nie znalezionoproject.assets.json" podczas zadania kompilacji, usuń warunek condition: ne(variables.CACHE_RESTORED, true) z zadania przywracania. Dzięki temu polecenie przywracania zostanie uruchomione i wygeneruje plik project.assets.json. Zadanie przywracania nie będzie ponownie pobierać pakietów, które są już obecne w odpowiednim folderze.

Porównanie wydajności

Buforowanie potoków znacznie skraca czas wymagany do przywrócenia zależności, co prowadzi do szybszej budowy. Poniższe porównanie ilustruje wpływ buforowania na czas wykonywania potoku dla dwóch różnych potoków:

• Bez buforowania (po prawej): zadanie przywracania trwało około 41 sekund.

• Z buforowaniem (po lewej): Dodaliśmy zadanie buforowania do drugiej sekwencji zadań i skonfigurowaliśmy zadanie przywracania do uruchomienia tylko wtedy, gdy wystąpi brak trafienia w pamięci podręcznej. Zadanie przywracania w tym przypadku zostało ukończone w ciągu zaledwie 8 sekund.

Poniżej znajduje się pełny YAML przepływ do odniesienia.

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages

steps:
- task: NuGetToolInstaller@1
  displayName: 'NuGet tool installer'

- task: Cache@2
  displayName: 'NuGet Cache'
  inputs:
    key: 'nuget | "$(Agent.OS)" | **/packages.lock.json,!**/bin/**,!**/obj/**'
    restoreKeys: |
       nuget | "$(Agent.OS)"
       nuget
    path: '$(NUGET_PACKAGES)'
    cacheHitVar: 'CACHE_RESTORED'

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  condition: ne(variables.CACHE_RESTORED, true)
  inputs:
    command: 'restore'
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Visual Studio Build'
  inputs:
    solution: '$(solution)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

Takie podejście dotyczy również projektów platformy .NET Core, pod warunkiem że projekt używa packages.lock.json do blokowania wersji pakietów. Możesz to włączyć, ustawiając RestorePackagesWithLockFile na True w pliku * Csproj* lub uruchamiając następujące polecenie: dotnet restore --use-lock-file.

Powiązana zawartość

• Buforowanie potoku

• Wdrażanie artefaktów pull request (wersja klasyczna)

• Wdrażanie na różnych etapach (wersja klasyczna)