Configurer le comportement en amont

  • Article

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

Avec azure Artifacts amont sources, les développeurs bénéficient de la commodité d’utiliser un flux unifié pour publier et consommer des packages à partir de flux Artifact et de registres publics populaires tels que NuGet.org ou npmjs.com. Auparavant, les flux Artifact combinent une liste de versions de package disponibles à partir du flux lui-même et de toutes les sources de amont configurées.

Illustration montrant le contenu d’un flux.

Le comportement en amont est une fonctionnalité qui permet aux développeurs de choisir s’ils souhaitent consommer des versions de package sources externes. Il régit les packages accessibles à partir des registres publics pour des packages spécifiques.

Une fois que amont comportement est activé, lorsqu’un package est publié sur votre flux Azure Artifacts, toute version du registre public est bloquée et n’est pas disponible pour le téléchargement.

Cette approche ajoute une couche de sécurité supplémentaire en empêchant l’exposition potentielle aux packages malveillants susceptibles d’avoir infiltré les registres publics.

Toutefois, les utilisateurs peuvent toujours désactiver le paramètre de comportement amont, ce qui leur permet de consommer des packages à partir des registres publics s’ils préfèrent le faire.

Remarque

Le nouveau comportement n’aura aucun impact sur les versions de package actuellement utilisées, car elles sont conservées dans la vue @local du flux.

Scénarios applicables

La section suivante illustre différents scénarios courants où le comportement de amont est déclenché pour bloquer les versions de package sources externes et d’autres scénarios où il n’est pas nécessaire de bloquer l’accès aux packages publics.

Les versions publiques sont bloquées

Version du package privé rendue publique

Dans ce scénario, une équipe dispose d’un package privé rendu public. Le comportement amont dans ce cas sera déclenché pour bloquer les nouvelles versions publiques (packages non approuvés).

Illustration montrant une version interne du package rendue publique.

Avoir des packages privés et publics

Dans ce scénario, si une équipe utilise une combinaison de packages privés et publics, l’activation du comportement amont bloque les nouvelles versions de package du registre public.

Illustration montrant les packages privés et publics disponibles.

Les versions publiques ne seront pas bloquées

Tous les packages sont privés*

Si tous les packages existants sont privés et que l’équipe n’a pas l’intention d’utiliser de packages publics, le nouveau comportement de amont n’a aucun effet sur le flux de travail de l’équipe dans ce scénario.

Illustration montrant le flux avec uniquement des packages privés.

Tous les packages sont publics

Dans ce scénario, si l’équipe consomme exclusivement des packages publics, qu’il s’agisse du registre public ou d’autres référentiels open source, le nouveau comportement de amont n’affecte pas son flux de travail de quelque manière que ce soit.

Illustration montrant le flux avec uniquement des packages publics.

Package public rendu privé

Dans ce cas, lorsqu’un package public est converti en package privé, le nouveau comportement de amont n’affecte pas le flux de travail de l’équipe de quelque manière que ce soit.

Illustration montrant un package converti d’un package public en privé.

Autoriser les versions externes

Remarque

Vous devez être propriétaire du flux pour autoriser les versions sources externes. Pour plus d’informations, consultez Autorisations de flux.

  1. Connectez-vous à votre organisation Azure DevOps puis accédez à votre projet.

  2. Sélectionnez Artefacts, puis sélectionnez votre flux dans le menu déroulant.

  3. Sélectionnez votre package, puis sélectionnez le bouton de sélection pour plus d’options. Sélectionnez Autoriser les versions sources externes.

    Capture d’écran montrant comment autoriser les versions sources externes.

  4. Sélectionnez le bouton bascule pour autoriser les versions externes. Sélectionnez Fermer lorsque vous avez terminé.

    Capture d’écran montrant comment activer des versions externes.

Autoriser les versions externes à l’aide de l’API REST

Autoriser les versions externes à l’aide de PowerShell

  1. Créez un jeton d’accès personnel avec l’empaquetage>en lecture, écriture et gestion des autorisations.

    Capture d’écran montrant comment sélectionner des autorisations d’empaquetage.

  2. Créez une variable d’environnement pour votre jeton d’accès personnel.

    $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"

  3. Convertissez votre jeton d’accès personnel en chaîne codée en baser64 et construisez l’en-tête de requête HTTP.

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

  4. Construisez votre URL de point de terminaison. Exemple : //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/amont ing ?api-version=6.1-preview.1

    • Flux dans l’étendue du projet :

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

    • Flux d’étendue de l’organisation :

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

Exécutez la commande suivante pour récupérer l’état de comportement amont de votre package. $url et $headers sont les mêmes variables que celles que nous avons utilisées dans la section précédente.

Invoke-RestMethod -Uri $url -Headers $headers