Udostępnij za pośrednictwem

Testowanie niestandardowych portów rejestru przy użyciu narzędzia vcpkg w usłudze Azure DevOps

Po skonfigurowaniu niestandardowego rejestru portów vcpkg możesz dodać ciągłą integrację, aby sprawdzić, czy wszystkie zależności można pomyślnie skompilować.

Główny rejestr vcpkg w firmie Microsoft/vcpkg jest testowany przez zespół vcpkg przy użyciu potoku ciągłej integracji (CI) w usłudze Azure DevOps. Dzięki temu dodanie nowych pakietów lub zaktualizowanie istniejących nie spowoduje przerwania użytkowników.

W tym artykule pokazano, jak skonfigurować środowisko ciągłej integracji w celu przetestowania portów vcpkg we własnym rejestrze.

Z tego artykułu dowiesz się, jak wykonywać następujące elementy:

  • Konfigurowanie binarnej pamięci podręcznej i pamięci podręcznej zasobów dla potoku usługi Azure DevOps
  • Konfigurowanie potoku do testowania portów rejestru

Wymagania wstępne

Konfigurowanie binarnej pamięci podręcznej i pamięci podręcznej zasobów dla potoków usługi Azure DevOps

Tworzenie dużej kolekcji portów jest kosztownym zadaniem zarówno w zakresie czasu, jak i mocy obliczeniowej. Zdecydowanie zalecamy, aby przed angażowaniem ciągłej integracji dla portów zainwestować w konfigurowanie binarnej pamięci podręcznej i pamięci podręcznej zasobów dla potoków usługi Azure DevOps.

Pamięć podręczna binarna zapewnia największą korzyść w scenariuszach ciągłej integracji, zapewniając, że niezmodyfikowane pakiety nie są komkompilowane w każdym uruchomieniu ciągłej integracji. Pamięć podręczna zasobów dubluje artefakty pobierane dla pakietów podczas przebiegu i używa buforowanych artefaktów w kolejnych uruchomieniach. Może również pomóc w rozwiązywaniu problemów, w których repozytorium nadrzędne jest zawodne: na przykład uszkodzony adres URL pobierania.

Aby uzyskać szczegółowe instrukcje dotyczące konfigurowania tych pamięci podręcznych, przeczytaj artykuły dotyczące buforowania binarnego i buforowania zasobów.

Przykład: włączanie buforowania zasobów i plików binarnych w potoku usługi Azure DevOps

steps: 
- task: NuGetAuthenticate@1

- script: $(Build.Repository.LocalPath)/vcpkg/vcpkg install --triplet=x64-windows
  displayName: some vcpkg task
  env:
    X_VCPKG_ASSET_SOURCES: "clear;x-azurl,https://my.domain.com/container,$(VcpkgAssetCache),readwrite"
    VCPKG_BINARY_SOURCES: "clear;nuget,https://my.domain.com/vcpkgBinaryCache/nuget/v3/index.json,readwrite"

W tym przykładzie pokazano, jak skonfigurować binarną pamięć podręczną i pamięć podręczną zasobów w potoku usługi Azure DevOps. Ten fragment kodu należy dostosować do użycia w pliku YAML własnego potoku.

Podzielenie tego fragmentu kodu:

X_VCPKG_ASSET_SOURCES to zmienna środowiskowa używana do konfigurowania pamięci podręcznych zasobów w narzędziu vcpkg. W tym przykładzie ustawiono wartość x-azurl,https://my.domain.com/container,$(VcpkgAssetCache),readwrite. Zaplecze x-azurl instruuje program vcpkg, aby używał kontenera usługi Azure Storage jako dostawcy magazynu. Następuje x-azurl po nim trzy parametry rozdzielone przecinkami (,).

  • https://my.domain.com/container to adres URL kontenera magazynu.
  • $(VcpkgAssetCache) to zmienna wpisu tajnego potoku zawierająca token SAS do uwierzytelniania w kontenerze magazynu.
  • readwrite ustawia uprawnienia do odczytu i zapisu dla pamięci podręcznej zasobów. Oznacza to, że ta pamięć podręczna zasobów jest używana do przechowywania artefaktów oraz przywracania artefaktów z niej.

VCPKG_BINARY_SOURCES to zmienna środowiskowa używana do konfigurowania binarnych pamięci podręcznych w narzędziu vcpkg. W tym przykładzie ustawiono wartość clear;nuget,https://my.domain.com/vcpkgBinaryCache/nuget/v3/index.json,readwrite. Umożliwia to zaplecze NuGet dla pamięci podręcznej binarnej przy użyciu źródła danych NuGet pod adresem https://my.domain.com/vcpkgBinaryCache/nuget/v3/index.json. Aby uwierzytelnić się w kanale informacyjnym NuGet, zapoznaj się z samouczkiem zawierającym instrukcje dotyczące konfigurowania uwierzytelniania NuGet za pomocą usługi ADO.

Aby uwierzytelnić się w źródłach nuGet usługi Azure Artifacts, należy dodać następujące zadanie zgodnie z oczekiwaniami w potoku. To zadanie powinno być również uruchamiane przed jakimkolwiek zadaniem obejmującym narzędzie vcpkg.

- task: NuGetAuthenticate@1

Jeśli używasz innego hosta dla źródeł danych NuGet, zapoznaj się z dokumentacją dotyczącą sposobu uwierzytelniania nuGet.

Dowiedz się więcej o tym, jak działają wszystkie te elementy, czytając dokumentację dotyczącą funkcji pamięci podręcznej zasobów i binarnej pamięci podręcznej .

Konfigurowanie potoku do testowania portów rejestru

Po skonfigurowaniu binarnej pamięci podręcznej i pamięci podręcznej zasobów dla środowiska ciągłej integracji następnym krokiem jest skonfigurowanie potoku w celu przetestowania wszystkich portów rejestru. Możesz zdecydować, czy ten potok jest uruchamiany zgodnie z harmonogramem, czy też jest wyzwalany przez nowe zatwierdzenia lub żądania ściągnięcia.

Główny rejestr vcpkg używa vcpkg ci polecenia , które zostało dostosowane do potrzeb projektu vcpkg i nie ma na celu pozostania stabilne lub używane przez konsumentów vcpkg. W związku z tym nie nadaje się do testowania własnych rejestrów vcpkg. Zalecamy wykonanie kroków opisanych w tym artykule.

Dołączanie wszystkich portów za pomocą pliku manifestu

Zamiast używać polecenia, zalecamy użycie pliku manifestu vcpkg ci do utworzenia kompilacji, która zależy od wszystkich pakietów w rejestrze.

Poniższy przykład tworzy plik manifestu w celu przetestowania wszystkich portów w hipotetycznym rejestrze vcpkg. Zastąp listę zależności, aby uwzględnić wszystkie porty w rejestrze i umieścić je w katalogu głównym repozytorium.

vcpkg.json

{
  "dependencies": [
    "beicode",
    "beison"
  ]
}

Twoje własne porty mogą mieć zależności od głównego rejestru vcpkg lub innych rejestrów innych firm, w tym przypadku należy dodać te rejestry w vcpkg-configuration.json pliku. Mimo że program vcpkg może rozpoznawać pakiety z głównego rejestru bez dodatkowej konfiguracji, zdecydowanie zalecamy jawne dodanie go do listy rejestrów na potrzeby kontroli wersji. Dzięki temu masz kontrolę nad zestawem bazowych wersji portów. Zapoznaj się z poleceniemvcpkg x-update-baseline, aby ułatwić zarządzanie punktem odniesienia rejestrów.

vcpkg-configuration.json

{
  "default-registry": null,
  "registries": [
    {
      "kind": "git",
      "repository": "https://github.com/Microsoft/vcpkg",
      "baseline": "42bb0d9e8d4cf33485afb9ee2229150f79f61a1f",
      "packages": "*"
    }
  ]
}

vcpkg.json Przeczytaj artykuły i vcpkg-configuration.json referencyjne, aby dowiedzieć się więcej. Zapoznaj się z dokumentacją trybu manifestu, aby dowiedzieć się, jak działają one razem.

Uzyskiwanie programu vcpkg w potoku usługi Azure DevOps

Jeśli używasz narzędzia vcpkg jako modułu podrzędnego w projekcie, możesz uzyskać repozytorium vcpkg w kroku, aby wyewidencjonować własny projekt, jak pokazano poniżej.

steps:
- checkout: self
  submodules: true

W przeciwnym razie musisz uzyskać narzędzie vcpkg, aby używać go w potoku. Dodaj następujące kroki, aby sklonować repozytorium vcpkg.

resources:
  repositories:
    - repository: vcpkgRepo
      type: github
      name: Microsoft/vcpkg
      endpoint: MyGitHubServiceConnection

steps:
  - checkout: vcpkgRepo

Aby sklonować repozytorium vcpkg, należy zdefiniować zasób repozytorium dla potoku. Poniższy fragment kodu pokazuje, jak dodać repozytorium vcpkg jako zasób. Aby połączyć potok z usługą GitHub, musisz skonfigurować usługę Połączenie ion.

Po wyewidencjonowaniu repozytorium vcpkg jako modułu podrzędnego lub sklonowaniu go z usługi GitHub należy uruchomić skrypt bootstrap narzędzia vcpkg.

steps:
  - script: vcpkg/bootstrap-vcpkg.sh

Po wykonaniu tych kroków należy pracować z plikiem wykonywalnym vcpkg.

Uruchamianie instalacji programu vcpkg w celu skompilowania portów

Ostatnim krokiem jest poinformowanie programu vcpkg o utworzeniu wszystkich portów. Być może zauważysz, że twój własny rejestr jest nieobecny w vcpkg-configuration.json utworzonym kilku krokach powyżej. Przyczyną jest to, że chcesz przetestować wersję portów aktualnie w katalogu roboczym, w przeciwieństwie do wersji opublikowanych w repozytorium.

W tym celu należy dodać porty rejestru jako porty nakładki, ustawiając zmienną VCPKG_OVERLAY_PORTS środowiskową w katalogu rejestru ports .

Poniższy fragment kodu przedstawia sposób konfigurowania portów rejestru jako portów nakładki i uruchamiania vcpkg install w trybie manifestu w celu zainstalowania wszystkich portów niestandardowych.

steps:
- script: $(Build.Repository.LocalPath)/vcpkg/vcpkg install
  env:
    X_VCPKG_ASSET_SOURCES: "clear;x-azurl,https://my.domain.com/container,$(VcpkgAssetCache),readwrite"
    VCPKG_BINARY_SOURCES: "clear;nuget,https://my.domain.com/demoBinaries/nuget/v3/index.json,readwrite"
    VCPKG_OVERLAY_PORTS: "$(Build.Repository.LocalPath)/ports"

W tym przykładzie przyjęto założenie, że vcpkg.json plik jest tworzony w katalogu głównym repozytorium rejestru i że repozytorium vcpkg jest dodawane jako moduł podrzędny.

Umieszczenie całego pliku YAML potoków powinno wyglądać podobnie do następującego:

.azure-pipelines/test-ports.yml

trigger:
- main

pool:
  vmImage: windows-latest

steps:
- checkout: self
  submodules: true

- task: NuGetAuthenticate@1

- script: $(Build.Repository.LocalPath)/vcpkg/bootstrap-vcpkg.bat
  displayName: Bootstrap vcpkg

- script: $(Build.Repository.LocalPath)/vcpkg/vcpkg install --triplet=x64-windows
  env:
    X_VCPKG_ASSET_SOURCES: "clear;x-azurl,https://my.domain.com/container,$(VcpkgAssetCache),readwrite"
    VCPKG_BINARY_SOURCES: "clear;nuget,https://my.domain.com/demoBinaries/nuget/v3/index.json,readwrite"
    VCPKG_OVERLAY_PORTS: "$(Build.Repository.LocalPath)/ports"

Jest to podstawowa struktura potoku ciągłej integracji do testowania portów rejestru. Może być wymagana dodatkowa praca w celu uwierzytelnienia w repozytoriach prywatnych lub w kanale informacyjnym NuGet.

Możesz również dodać kroki automatyzacji generowania vcpkg.json pliku lub kroku sprawdzającego, czy porty nowo dodane do rejestru nie są pominięte w testach.

Następne kroki

Poniższe artykuły mogą być przydatne podczas konfigurowania środowiska ciągłej integracji.