Share via

Skonfiguruj zachowanie nadrzędne

  • Artykuł

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

Dzięki nadrzędnym źródłom usługi Azure Artifacts deweloperzy uzyskują wygodę korzystania z ujednoliconego źródła danych zarówno do publikowania, jak i używania pakietów z kanałów informacyjnych artefaktów oraz popularnych rejestrów publicznych, takich jak NuGet.org lub npmjs.com. Wcześniej źródła artefaktów połączyły listę dostępnych wersji pakietów zarówno z samego kanału informacyjnego, jak i wszystkich skonfigurowanych źródeł nadrzędnych.

Ilustracja przedstawiająca zawartość kanału informacyjnego.

Zachowanie nadrzędne to funkcja, która umożliwia deweloperom wybór, czy chcą korzystać z wersji pakietów źródłowych zewnętrznych. Określa, które pakiety są dostępne z publicznych rejestrów dla określonych pakietów.

Po włączeniu zachowania nadrzędnego po opublikowaniu pakietu w kanale informacyjnym usługi Azure Artifacts każda wersja z rejestru publicznego zostanie zablokowana i nie zostanie udostępniona do pobrania.

Takie podejście dodaje dodatkową warstwę zabezpieczeń, zapobiegając potencjalnemu narażeniu na złośliwe pakiety, które mogły przeniknąć do publicznych rejestrów.

Jednak użytkownicy nadal mogą dezaktywować ustawienie zachowania nadrzędnego, umożliwiając im korzystanie z pakietów z publicznych rejestrów, jeśli wolisz to zrobić.

Uwaga

Nowe zachowanie nie będzie miało wpływu na żadne wersje pakietów, które są obecnie używane, ponieważ są one zachowywane w widoku @local kanału informacyjnego.

Odpowiednie scenariusze

W poniższej sekcji przedstawiono różne typowe scenariusze, w których zachowanie nadrzędne jest wyzwalane w celu blokowania wersji pakietów źródłowych zewnętrznych i innych scenariuszy, w których nie ma potrzeby blokowania dostępu do pakietów publicznych.

Wersje publiczne są blokowane

Publiczna wersja pakietu prywatnego

W tym scenariuszu zespół ma pakiet prywatny, który został upubliczniony. Zachowanie nadrzędne w tym przypadku zostanie wyzwolone w celu zablokowania nowych wersji publicznych (niezaufanych pakietów).

Ilustracja przedstawiająca publiczną wersję pakietu wewnętrznego.

Posiadanie zarówno prywatnych, jak i publicznych pakietów

W tym scenariuszu, jeśli zespół korzysta z kombinacji prywatnych i publicznych pakietów, włączenie zachowania nadrzędnego blokuje wszelkie nowe wersje pakietów z rejestru publicznego.

Ilustracja przedstawiająca dostępne pakiety prywatne i publiczne.

Wersje publiczne nie będą blokowane

Wszystkie pakiety są prywatne*

Jeśli wszystkie istniejące pakiety są prywatne, a zespół nie planuje używania żadnych pakietów publicznych, nowe zachowanie nadrzędne nie ma wpływu na przepływ pracy zespołu w tym scenariuszu.

Ilustracja przedstawiająca kanał informacyjny z tylko pakietami prywatnymi.

Wszystkie pakiety są publiczne

W tym scenariuszu, jeśli zespół korzysta wyłącznie z pakietów publicznych, niezależnie od tego, czy z rejestru publicznego, czy innych repozytoriów typu open source, nowe zachowanie nadrzędne nie ma wpływu na ich przepływ pracy w żaden sposób.

Ilustracja przedstawiająca kanał informacyjny z tylko pakietami publicznymi.

Pakiet publiczny został udostępniony jako prywatny

W takiej sytuacji, gdy pakiet publiczny jest konwertowany na pakiet prywatny, nowe zachowanie nadrzędne nie ma wpływu na przepływ pracy zespołu w żaden sposób.

Ilustracja przedstawiająca pakiet przekonwertowany z publicznego na prywatny.

Zezwalaj na wersje zewnętrzne

Uwaga

Aby zezwolić na wersje źródłowe zewnętrznie, musisz być właścicielem kanału informacyjnego. Aby uzyskać więcej informacji, zobacz Uprawnienia kanału informacyjnego.

  1. Zaloguj się do organizacji usługi Azure DevOps, a następnie przejdź do projektu.

  2. Wybierz pozycję Artefakty, a następnie wybierz źródło danych z menu rozwijanego.

  3. Wybierz pakiet, a następnie wybierz przycisk wielokropka, aby uzyskać więcej opcji. Wybierz pozycję Zezwalaj na wersje źródłowe zewnętrznie.

    Zrzut ekranu przedstawiający sposób zezwalania na wersje źródłowe zewnętrznie.

  4. Wybierz przycisk przełącznika, aby zezwolić na wersje zewnętrzne. Po zakończeniu wybierz pozycję Zamknij .

    Zrzut ekranu przedstawiający sposób włączania wersji zewnętrznych.

Zezwalaj na wersje zewnętrzne przy użyciu interfejsu API REST

Zezwalaj na wersje zewnętrzne przy użyciu programu PowerShell

  1. Utwórz osobisty token dostępu z uprawnieniami do>odczytu, zapisu i zarządzania pakietami.

    Zrzut ekranu przedstawiający sposób wybierania uprawnień do tworzenia pakietów.

  2. Utwórz zmienną środowiskową dla osobistego tokenu dostępu.

    $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"

  3. Przekonwertuj osobisty token dostępu na ciąg zakodowany w formacie baser64 i skonstruuj nagłówek żądania HTTP.

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

  4. Skonstruuj adres URL punktu końcowego. Przykład: //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/upstreaming?api-version=6.1-preview.1

    • Źródło danych o zakresie projektu:

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

    • Kanał informacyjny o zakresie organizacji:

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

Uruchom następujące polecenie, aby pobrać nadrzędny stan zachowania pakietu. $url i $headers są tymi samymi zmiennymi, które użyliśmy w poprzedniej sekcji.

Invoke-RestMethod -Uri $url -Headers $headers