Testare le porte del Registro di sistema personalizzate usando vcpkg con Azure DevOps

Articolo
02/27/2024

Dopo aver configurato un registro personalizzato di porte vcpkg, è possibile aggiungere un'integrazione continua per verificare che tutte le dipendenze possano essere compilate correttamente.

Il registro vcpkg principale in Microsoft/vcpkg viene testato dal team vcpkg usando una pipeline di integrazione continua (CI) con Azure DevOps. Ciò garantisce che l'aggiunta di nuovi pacchetti o l'aggiornamento di quelli esistenti non interrompa i consumer.

In questo articolo viene illustrato come configurare un ambiente CI per testare le porte vcpkg nel proprio registro.

In questo articolo si apprenderà come:

Configurare una cache binaria e una cache degli asset per la pipeline di Azure DevOps
Configurare una pipeline per testare le porte del Registro di sistema

Prerequisiti

Un account Azure DevOps
Registro Git vcpkg personalizzato
Completamento delle esercitazioni sulla memorizzazione nella cache binaria e nella memorizzazione nella cache degli asset.
Informazioni sulle pipeline ADO

Configurare una cache binaria e una cache degli asset per le pipeline di Azure DevOps

La creazione di una grande raccolta di porte è un'attività costosa sia in termini di tempo che di potenza di calcolo. È consigliabile che prima di coinvolgere ci per le porte, si investe nella configurazione di una cache binaria e di una cache di asset per le pipeline di Azure DevOps.

Una cache binaria offre il massimo vantaggio per gli scenari di integrazione continua, assicurandosi che i pacchetti non modificati non vengano ricompilati in ogni esecuzione ci. Una cache degli asset rispecchia gli artefatti scaricati per i pacchetti durante un'esecuzione e usa gli artefatti memorizzati nella cache nelle esecuzioni successive. Può anche aiutare a mitigare i problemi in cui il repository upstream non è affidabile, ad esempio un URL di download interrotto.

Per istruzioni dettagliate su come configurare queste cache, leggere gli articoli sulla memorizzazione nella cache binaria e sulla memorizzazione nella cache degli asset.

Esempio: Abilitare la memorizzazione nella cache di asset e binari in una pipeline di 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"

Questo esempio illustra come configurare una cache binaria e una cache degli asset in una pipeline di Azure DevOps. È consigliabile adattare questo frammento di codice da usare nel file YAML della pipeline.

Suddivisione di questo frammento di codice:

X_VCPKG_ASSET_SOURCES è la variabile di ambiente usata per configurare le cache degli asset in vcpkg. In questo esempio viene impostato su x-azurl,https://my.domain.com/container,$(VcpkgAssetCache),readwrite. Il x-azurl back-end indica a vcpkg di usare un contenitore Archiviazione di Azure come provider di archiviazione. l'oggetto x-azurl è seguito da tre parametri separati da virgole (,).

https://my.domain.com/container è un URL del contenitore di archiviazione.
$(VcpkgAssetCache) è una variabile privata della pipeline che contiene un token di firma di accesso condiviso per l'autenticazione nel contenitore di archiviazione.
readwrite imposta le autorizzazioni di lettura e scrittura per la cache degli asset. Ciò significa che questa cache degli asset viene usata per archiviare gli artefatti e per ripristinare gli artefatti da esso.

VCPKG_BINARY_SOURCES è la variabile di ambiente usata per configurare le cache binarie in vcpkg. In questo esempio viene impostato su clear;nuget,https://my.domain.com/vcpkgBinaryCache/nuget/v3/index.json,readwrite. In questo modo viene abilitato il back-end NuGet per la cache binaria usando il feed NuGet in https://my.domain.com/vcpkgBinaryCache/nuget/v3/index.json. Potrebbero essere necessari alcuni passaggi aggiuntivi per eseguire l'autenticazione nel feed NuGet, leggere l'esercitazione per istruzioni per configurare l'autenticazione NuGet con ADO.

L'attività seguente deve essere aggiunta così come è nella pipeline per l'autenticazione ai feed NuGet di Azure Artifacts. Questa attività deve essere eseguita anche prima di qualsiasi attività che coinvolge vcpkg.

- task: NuGetAuthenticate@1

Se si usa un host diverso per i feed NuGet, leggere la documentazione su come autenticare NuGet.

Per altre informazioni sul funzionamento di tutti questi elementi, leggere la documentazione sulle funzionalità della cache degli asset e della cache binaria.

Configurare una pipeline per testare le porte del Registro di sistema

Dopo aver configurato una cache binaria e una cache degli asset per l'ambiente CI, il passaggio successivo consiste nel configurare una pipeline per testare tutte le porte del Registro di sistema. È possibile decidere se questa pipeline viene eseguita in base a una pianificazione o se viene attivata da nuovi commit o richieste pull.

Il registro vcpkg principale usa il vcpkg ci comando , che è stato personalizzato in base alle esigenze del progetto vcpkg e non è destinato a rimanere stabile o essere usato dai consumer di vcpkg. Di conseguenza, non è adatto per il test dei registri vcpkg personalizzati. È consigliabile seguire invece i passaggi descritti in questo articolo.

Usare un file manifesto per includere tutte le porte

Anziché usare il vcpkg ci comando , è consigliabile usare un file manifesto per creare una compilazione che dipende da tutti i pacchetti nel Registro di sistema.

Nell'esempio seguente viene creato un file manifesto per testare tutte le porte in un registro vcpkg ipotetico. Sostituire l'elenco delle dipendenze per includere tutte le porte nel Registro di sistema e inserirle nella radice del repository.

vcpkg.json

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

Le porte personalizzate possono avere dipendenze dal registro vcpkg principale o da altri registri di terze parti, nel qual caso è necessario aggiungere tali registri in un vcpkg-configuration.json file. Anche se vcpkg può risolvere i pacchetti dal Registro di sistema principale senza configurazione aggiuntiva, è consigliabile aggiungerlo in modo esplicito all'elenco registri per scopi di controllo della versione. In questo modo si garantisce il controllo del set di versioni delle porte sottostanti. Consultare il vcpkg x-update-baseline comando per facilitare la gestione della baseline dei registri.

vcpkg-configuration.json

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

Per altre informazioni, vedere gli vcpkg.json articoli di riferimento e vcpkg-configuration.json . E la documentazione relativa alla modalità manifesto per informazioni su come interagiscono.

Acquisire vcpkg nella pipeline di Azure DevOps

Se si usa vcpkg come modulo secondario nel progetto, è possibile ottenere il repository vcpkg nel passaggio per estrarre il proprio progetto, come illustrato di seguito.

steps:
- checkout: self
  submodules: true

In caso contrario, è necessario acquisire vcpkg per usarlo nella pipeline. Aggiungere i passaggi seguenti per clonare il repository vcpkg.

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

steps:
  - checkout: vcpkgRepo

Per clonare il repository vcpkg è necessario definire una risorsa del repository per la pipeline. Il frammento di codice seguente illustra come aggiungere il repository vcpkg come risorsa, è necessario configurare un'Connessione del servizio per connettere la pipeline a GitHub.

Dopo aver estratto il repository vcpkg come modulo secondario o clonandolo da GitHub, è necessario eseguire lo script bootstrap di vcpkg.

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

Al termine di questi passaggi, è necessario avere un eseguibile vcpkg da usare.

Eseguire vcpkg install per compilare le porte

L'ultimo passaggio consiste nell'indicare a vcpkg di compilare tutte le porte. Si potrebbe aver notato che il proprio registro è assente dal vcpkg-configuration.json creato un paio di passaggi precedenti. Il motivo è che si vuole testare la versione delle porte attualmente nella directory di lavoro anziché le versioni pubblicate nel repository.

A tale scopo, è necessario aggiungere le porte del Registro di sistema come porte di sovrapposizione impostando la variabile di ambiente sulla VCPKG_OVERLAY_PORTS directory del Registro di ports sistema.

Il frammento di codice seguente illustra come configurare le porte del Registro di sistema come porte di sovrapposizione ed è in esecuzione vcpkg install in modalità manifesto per installare tutte le porte personalizzate.

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"

In questo esempio si presuppone che il vcpkg.json file venga creato nella radice del repository del Registro di sistema e che il repository vcpkg venga aggiunto come modulo secondario.

L'insieme del file YAML delle pipeline dovrebbe essere simile al seguente:

.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"

Si tratta della struttura di base per una pipeline CI per testare le porte del Registro di sistema. Potrebbe essere necessario eseguire alcune operazioni aggiuntive per l'autenticazione nei repository privati o nel feed NuGet.

È anche possibile aggiungere passaggi per automatizzare la generazione del vcpkg.json file o un passaggio che verifica che le porte appena aggiunte al Registro di sistema non vengano interrotte dai test.

Passaggi successivi

Gli articoli seguenti possono essere utili per la configurazione di un ambiente CI.

Condividi tramite