Konfigurieren des Upstreamverhaltens

  • Artikel

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

Mit Azure Artifacts-Upstreamquellen können Entwickler einen einheitlichen Feed nutzen, um Pakete aus Artefaktfeeds und beliebten öffentlichen Registrierungen wie NuGet.org oder npmjs.com zu veröffentlichen und zu nutzen. Zuvor kombinierte Artefaktfeed eine Liste der verfügbaren Paketversionen sowohl aus dem Feed selbst als auch aus allen konfigurierten Upstreamquellen.

Eine Abbildung, die den Inhalt eines Feeds zeigt.

Das Upstream-Verhalten ist ein Feature, mit dem Entwickler auswählen können, ob sie extern stammende Paketversionen nutzen möchten. Sie regelt, welche Pakete von den öffentlichen Registern für bestimmte Pakete zugänglich sind.

Sobald das Upstream-Verhalten aktiviert ist, wird beim Veröffentlichen eines Pakets in Ihrem Azure Artifacts-Feed jede Version aus der öffentlichen Registrierung blockiert und nicht zum Download zur Verfügung gestellt.

Dieser Ansatz fügt eine zusätzliche Sicherheitsebene hinzu, indem potenzielle Gefährdungen durch böswillige Pakete verhindert werden, die möglicherweise die öffentlichen Register infiltriert haben.

Benutzer können die Upstream-Verhaltenseinstellung jedoch weiterhin deaktivieren, sodass sie Pakete aus den öffentlichen Registrierungen nutzen können, wenn sie dies bevorzugen.

Hinweis

Das neue Verhalten wirkt sich nicht auf paketversionen aus, die derzeit verwendet werden, da sie in der @local Ansicht des Feeds beibehalten werden.

Zutreffende Szenarios

Im folgenden Abschnitt werden verschiedene häufige Szenarien veranschaulicht, in denen das Upstream-Verhalten ausgelöst wird, um externe Paketversionen zu blockieren, und andere Szenarien, in denen der Zugriff auf öffentliche Pakete nicht blockiert werden muss.

Öffentliche Versionen werden blockiert.

Private Paketversion, die öffentlich gemacht wurde

In diesem Szenario verfügt ein Team über ein privates Paket, das öffentlich gemacht wurde. Das Upstreamverhalten in diesem Fall wird ausgelöst, um neue öffentliche Versionen (nicht vertrauenswürdige Pakete) zu blockieren.

Abbildung einer internen Paketversion, die öffentlich gemacht wurde.

Sowohl private als auch öffentliche Pakete

Wenn ein Team in diesem Szenario eine Kombination aus privaten und öffentlichen Paketen verwendet, blockiert das Upstreamverhalten alle neuen Paketversionen aus der öffentlichen Registrierung.

Abbildung der verfügbaren privaten und öffentlichen Pakete.

Öffentliche Versionen werden nicht blockiert

Alle Pakete sind privat*

Wenn alle vorhandenen Pakete privat sind und das Team keine öffentlichen Pakete verwenden möchte, hat das neue Upstreamverhalten keine Auswirkungen auf den Workflow des Teams in diesem Szenario.

Abbildung eines Feeds mit nur privaten Paketen.

Alle Pakete sind öffentlich

Wenn das Team in diesem Szenario ausschließlich öffentliche Pakete nutzt, unabhängig davon, ob aus der öffentlichen Registrierung oder anderen Open-Source-Repositorys, wirkt sich das neue Upstreamverhalten nicht auf seinen Workflow aus.

Abbildung eines Feeds mit nur öffentlichen Paketen.

Öffentliches Paket, das privat gemacht wurde

Wenn ein öffentliches Paket in ein privates Paket konvertiert wird, wirkt sich das neue Upstreamverhalten in diesem Fall nicht auf den Workflow des Teams aus.

Abbildung eines Pakets, das von öffentlich in privat konvertiert wurde.

Externe Versionen zulassen

Hinweis

Sie müssen ein Feedbesitzer sein, um extern stammende Versionen zuzulassen. Weitere Informationen finden Sie unter Feedberechtigungen.

  1. Melden Sie sich bei Ihrer Azure DevOps-Organisation an, und navigieren Sie dann zu Ihrem Projekt.

  2. Wählen Sie Artefakte und dann Ihren Feed im Dropdownmenü aus.

  3. Wählen Sie Ihr Paket aus, und wählen Sie dann die Schaltfläche mit den Auslassungspunkten für weitere Optionen aus. Wählen Sie "Externe Versionen zulassen" aus.

    Screenshot, der zeigt, wie externe Versionen zugelassen werden.

  4. Wählen Sie die Umschaltfläche aus, um externe Versionen zuzulassen. Wählen Sie "Schließen" aus, wenn Sie fertig sind.

    Screenshot, der zeigt, wie externe Versionen aktiviert werden.

Zulassen externer Versionen mithilfe der REST-API

Zulassen externer Versionen mit PowerShell

  1. Erstellen Sie ein persönliches Zugriffstoken mit "Lesen>", "Schreiben" und "Verwalten von Berechtigungen".

    Screenshot, der zeigt, wie Sie Paketberechtigungen auswählen.

  2. Erstellen Sie eine Umgebungsvariable für Ihr persönliches Zugriffstoken.

    $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"

  3. Konvertieren Sie Ihr persönliches Zugriffstoken in baser64-codierte Zeichenfolge, und erstellen Sie den HTTP-Anforderungsheader.

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

  4. Erstellen Sie Ihre Endpunkt-URL. Beispiel: //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/upstreaming?api-version=6.1-preview.1

    • Projektbezogener Feed:

      $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 mit Organisationsbereich:

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

Führen Sie den folgenden Befehl aus, um den Upstreamverhaltenszustand des Pakets abzurufen. $url und $headers sind die gleichen Variablen, die wir im vorherigen Abschnitt verwendet haben.

Invoke-RestMethod -Uri $url -Headers $headers