Udostępnij za pośrednictwem

Buforowanie pakietów NuGet

  • Artykuł

Azure DevOps Services

Dzięki buforowaniu potoku można skrócić czas kompilacji, buforując zależności do ponownego użycia w kolejnych uruchomieniach. Z tego artykułu dowiesz się, jak używać zadania Cache do buforowania i przywracania pakietów NuGet.

Uwaga

Buforowanie potoków nie jest obsługiwane w potokach wersji klasycznych.

Blokowanie zależności

Aby skonfigurować zadanie pamięci podręcznej, należy najpierw zablokować zależności projektu i utworzyć plik package.lock.json. Skrót zawartości pliku blokady zostanie użyty do wygenerowania unikatowego klucza pamięci podręcznej.

Aby zablokować zależności projektu, ustaw właściwość RestorePackagesWithLockFile w pliku csproj na wartość true. Przywracanie nuGet generuje plik blokady packages.lock.json w katalogu głównym projektu. Upewnij się, że plik packages.lock.json jest sprawdzany w kodzie źródłowym.

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

Buforowanie pakietów NuGet

Musimy utworzyć zmienną pipeline'u, aby wskazywała lokalizację naszych pakietów na agencie, na którym działa pipeline.

W tym przykładzie zawartość packages.lock.json jest hashowana, tworząc dynamiczny klucz pamięci podręcznej. Gwarantuje to, że za każdym razem, gdy plik zostanie zmodyfikowany, zostanie wygenerowany nowy klucz pamięci podręcznej.

Zrzut ekranu przedstawiający sposób generowania klucza pamięci podręcznej w usłudze Azure Pipelines. 

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

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

Uwaga

Pamięci podręczne są niezmienne, po utworzeniu pamięci podręcznej nie można modyfikować jego zawartości.

Przywracanie pamięci podręcznej

To zadanie zostanie uruchomione tylko wtedy, gdy zmienna CACHE_RESTORED ma wartość false.

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

Uwaga

Jeśli używasz systemu Ubuntu 24.04 lub nowszego, musisz użyć zadania NuGetAuthenticate z interfejsem wiersza polecenia platformy .NET zamiast zadania NuGetCommand@2. Aby uzyskać więcej informacji, zobacz Support for newer Ubuntu hosted images (Obsługa nowszych obrazów hostowanych w systemie Ubuntu).

Jeśli podczas zadania kompilacji wystąpi komunikat o błędzie "project.assets.json nie znaleziono", możesz go rozwiązać, usuwając warunek condition: ne(variables.CACHE_RESTORED, true) z zadania przywracania. W ten sposób polecenie przywracania jest wykonywane, generując plik project.assets.json. Zadanie przywracania nie pobierze pakietów, które są już obecne w odpowiednim folderze.

Uwaga

Potok może zawierać co najmniej jedno zadanie buforowania, a zadania i zadania w tym samym potoku mogą uzyskiwać dostęp do tej samej pamięci podręcznej i współużytkować je.

Porównanie wydajności

Buforowanie potoków to doskonały sposób na przyspieszenie wykonywania potoku. Oto porównanie wydajności równoległej dla dwóch różnych potoków. Przed dodaniem zadania buforowania (po prawej) zadanie przywracania trwało około 41 sekund. Dodaliśmy zadanie buforowania do drugiego potoku (po lewej) i skonfigurowaliśmy zadanie przywracania do uruchomienia po napotkaniu chybienia pamięci podręcznej. Wykonanie zadania przywracania w tym przypadku trwało 8 sekund.

Zrzut ekranu przedstawiający wydajność potoku z buforowaniem i bez buforowania.

Poniżej znajduje się pełny potok YAML do celów referencyjnych:

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 jest również prawidłowe w przypadku projektów platformy .NET Core, jeśli 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 za pomocą następującego polecenia: dotnet restore --use-lock-file.