Autorisation d’une prébuild à accéder à d’autres dépôts

Vous pouvez autoriser votre prébuild à avoir accès à d’autres référentiels GitHub afin qu’elle puisse être générée avec succès.

Qui peut utiliser cette fonctionnalité ?

People with admin access to a repository can configure prebuilds for the repository.

Les paramètres au niveau du dépôt de GitHub Codespaces sont disponibles pour tous les dépôts appartenant à des comptes personnels.

Pour les dépôts appartenant à des organisations, les paramètres au niveau du dépôt de GitHub Codespaces sont disponibles pour les organisations sur les plans GitHub Team et GitHub Enterprise. Pour accéder aux paramètres, l’organisation ou son entreprise parente doit avoir ajouté un mode de paiement et défini une limite de dépense pour GitHub Codespaces. Pour plus d’informations, consultez « Choisir qui possède et achète les codespaces dans votre organisation » et « Plans de GitHub ».

Dans cet article

Par défaut, le workflow GitHub Actions d’une configuration de prébuild peut uniquement accéder au contenu de son propre dépôt. Votre projet peut utiliser des ressources supplémentaires, situées ailleurs, pour créer l’environnement de développement.

Autorisation d’une prébuild à accéder en lecture à des ressources externes

Vous pouvez configurer l’accès en lecture à d’autres dépôts GitHub avec le même propriétaire de dépôt, en spécifiant des autorisations dans le fichier devcontainer.json utilisé par votre configuration de prébuild. Pour plus d’informations, consultez « Gestion de l’accès à d’autres dépôts dans votre codespace ».

Note

  • Vous ne pouvez accorder qu'une autorisation d'accès en lecture de cette manière, et le propriétaire du référentiel cible doit être le même que celui du référentiel pour lequel vous créez une préversion. Par exemple, si vous créez une configuration de préversion de octo-org/octocatrepository, vous pourrez accorder des autorisations de lecture à d'autres référentiels tels que asocto-org/octodemo, si cela est spécifié dans le fichier devcontainer.json, à condition que vous disposiez vous-même des autorisations.
  • Vous ne pouvez pas utiliser des caractères génériques pour spécifier des référentiels. Vous devez définir des autorisations pour chaque référentiel auquel vous souhaitez accorder l'accès.

Lorsque vous créez ou modifiez une configuration de prébuild pour un fichier devcontainer.json qui configure l’accès en lecture à d’autres dépôts avec le même propriétaire de dépôt, vous êtes invité à accorder ces autorisations lorsque vous cliquez sur Créer ou Mettre à jour. Pour plus d’informations, consultez « Configuration des prébuilds ».

Autorisation d’une prébuild à accéder en écriture à des ressources externes

Si votre projet a besoin d’un accès en écriture sur les ressources ou si les ressources externes résident dans un référentiel avec un propriétaire autre que celui du référentiel pour lequel vous créez une configuration de prébuild, vous pouvez utiliser un personal access token pour accorder cet accès.

Vous devez créer un compte personnel et utiliser ce compte pour créer un personal access token (classic) avec les étendues appropriées.

  1. Créez un compte personnel sur GitHub.

    Warning

    Même si vous pouvez générer le personal access token (classic) en utilisant votre compte personnel existant, nous vous recommandons vivement de créer un autre compte doté uniquement d’un accès aux dépôts cibles nécessaires pour votre scénario. En effet, l’autorisation repository du jeton d’accès octroie un accès à tous les dépôts auxquels le compte a accès. Pour plus d’informations, consultez « Création d’un compte sur GitHub » et « Durcissement de la sécurité pour GitHub Actions ».

  2. Octroyez au nouveau compte un accès en lecture aux dépôts nécessaires. Pour plus d’informations, consultez « Gestion de l’accès d’une personne à un dépôt d’organisation ».

  3. En étant connecté au nouveau compte, créez un personal access token (classic) avec l’étendue repo. Éventuellement, si la prébuild a besoin de télécharger des packages à partir de GitHub Container registry, sélectionnez aussi l’étendue read:packages. Pour plus d’informations, consultez « Gestion de vos jetons d'accès personnels ».

    Capture d’écran des options de configuration « Sélectionner les étendues » pour un personal access token (classic), avec les étendues « référentiel » et « read:packages » sélectionnées.

    Si la prébuild utilise un package issu de GitHub Container registry, vous avez besoin soit d’octroyer au nouveau compte un accès au package, soit de configurer le package de sorte à ce qu’il hérite des autorisations d’accès du dépôt dont vous créez la prébuild. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».

  4. Copiez la chaîne du jeton. Vous allez l’attribuer à un secret de dépôt Codespaces.

  5. Reconnectez-vous au compte qui dispose d’un accès administrateur au dépôt.

  6. Dans le dépôt pour lequel vous voulez créer des prébuilds GitHub Codespaces, créez un secret de dépôt Codespaces appelé CODESPACES_PREBUILD_TOKEN, en lui donnant la valeur du jeton que vous avez créé et copié. Pour plus d’informations, consultez « Gestion des secrets d’environnement de développement pour votre référentiel ou votre organisation ».

Le personal access token est utilisé pour toutes les prébuilds ultérieures créées pour votre dépôt. Contrairement à d’autres secrets de référentiel Codespaces, le secret CODESPACES_PREBUILD_TOKEN est utilisé uniquement pour créer la prébuild. Il n’est pas disponible pour être utilisé dans des codespaces créés à partir de votre référentiel.

Pour aller plus loin