Condividi tramite

Configurare il comportamento upstream

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Con le origini upstream di Azure Artifacts, gli sviluppatori ottengono la comodità di usare un feed unificato per pubblicare e usare pacchetti dai feed artifact e dai registri pubblici più diffusi, ad esempio NuGet.org o npmjs.com. In precedenza, Artifact feed combinava un elenco di versioni dei pacchetti disponibili sia dal feed stesso che da tutte le origini upstream configurate.

Figura che mostra il contenuto di un feed.

Il comportamento upstream è una funzionalità che consente agli sviluppatori di scegliere se vogliono utilizzare versioni di pacchetti con origine esterna. Controlla quali pacchetti sono accessibili dai registri pubblici per pacchetti specifici.

Una volta abilitato il comportamento upstream, quando un pacchetto viene pubblicato nel feed di Azure Artifacts, qualsiasi versione del Registro di sistema pubblico viene bloccata e non resa disponibile per il download.

Questo approccio aggiunge un ulteriore livello di sicurezza impedendo potenziali esposizione a pacchetti dannosi che potrebbero essersi infiltrati nei registri pubblici.

Tuttavia, gli utenti possono comunque disattivare l'impostazione del comportamento upstream, consentendo loro di utilizzare pacchetti dai registri pubblici se preferiscono farlo.

Nota

Il nuovo comportamento non influirà sulle versioni del pacchetto attualmente in uso, perché vengono mantenute all'interno della visualizzazione @local del feed.

Scenari applicabili

La sezione seguente illustra vari scenari comuni in cui viene attivato il comportamento upstream per bloccare le versioni dei pacchetti con origine esterna e altri scenari in cui non è necessario bloccare l'accesso ai pacchetti pubblici.

Le versioni pubbliche sono bloccate

Versione del pacchetto privato resa pubblica

In questo scenario, un team ha un pacchetto privato reso pubblico. In questo caso verrà attivato il comportamento upstream per bloccare le nuove versioni pubbliche (pacchetti non attendibili).

Figura che mostra una versione interna del pacchetto resa pubblica.

Avere pacchetti sia privati che pubblici

In questo scenario, se un team usa una combinazione di pacchetti privati e pubblici, l'abilitazione del comportamento upstream blocca le nuove versioni dei pacchetti dal Registro di sistema pubblico.

Figura che mostra i pacchetti privati e pubblici disponibili.

Le versioni pubbliche non verranno bloccate

Tutti i pacchetti sono privati*

Se tutti i pacchetti esistenti sono privati e il team non prevede l'uso di pacchetti pubblici, il nuovo comportamento upstream non ha alcun effetto sul flusso di lavoro del team in questo scenario.

Figura che mostra il feed con solo pacchetti privati.

Tutti i pacchetti sono pubblici

In questo scenario, se il team usa esclusivamente pacchetti pubblici, sia dal registro pubblico che da altri repository open source, il nuovo comportamento upstream non influisce in alcun modo sul flusso di lavoro.

Figura che mostra il feed con solo pacchetti pubblici.

Pacchetto pubblico reso privato

In questo caso, quando un pacchetto pubblico viene convertito in un pacchetto privato, il nuovo comportamento upstream non influisce in alcun modo sul flusso di lavoro del team.

Figura che mostra un pacchetto convertito da pubblico a privato.

Consenti versioni esterne

Nota

È necessario essere un proprietario del feed per consentire versioni con origine esterna. Per altre informazioni, vedere Autorizzazioni feed.

  1. Accedere all'organizzazione di Azure DevOps e passare al progetto.

  2. Selezionare Artefatti e quindi selezionare il feed dal menu a discesa.

  3. Selezionare il pacchetto e quindi selezionare il pulsante con i puntini di sospensione per altre opzioni. Selezionare Consenti versioni esterne di origine.

    Screenshot che mostra come consentire versioni con origine esterna.

  4. Selezionare l'interruttore per consentire le versioni esterne. Al termine, selezionare Chiudi .

    Screenshot che mostra come abilitare le versioni esterne.

Consenti versioni esterne tramite l'API REST

Consenti versioni esterne con PowerShell

  1. Creare un token di accesso personale con autorizzazioni di lettura, scrittura e gestione dei pacchetti>.

    Screenshot che mostra come selezionare le autorizzazioni per la creazione di pacchetti.

  2. Creare una variabile di ambiente per il token di accesso personale.

    $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"

  3. Convertire il token di accesso personale in una stringa con codifica Baser64 e costruire l'intestazione della richiesta HTTP.

    $token = [Convert]::ToBase64String(([Text.Encoding]::ASCII.GetBytes("username:$env:PatVar")))
$headers = @{
    Authorization = "Basic $token"
}

  4. Costruire l'URL dell'endpoint. Esempio: //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/upstreaming?api-version=6.1-preview.1

    • Feed con ambito progetto:

      $url = "https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_apis/packaging/feeds/<FEED_NAME>/<PROTOCOL>/packages/<PACKAGE_NAME>/upstreaming?api-version=6.1-preview.1"

    • Feed con ambito organizzazione:

      $url = "https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/_apis/packaging/feeds/<FEED_NAME>/<PROTOCOL>/packages/<PACKAGE_NAME>/upstreaming?api-version=6.1-preview.1"

Eseguire il comando seguente per recuperare lo stato del comportamento upstream del pacchetto. $url e $headers sono le stesse variabili usate nella sezione precedente.

Invoke-RestMethod -Uri $url -Headers $headers