Référence des flux de travail réutilisables

Accès aux workflows réutilisables

Un workflow réutilisable peut être utilisé par un autre workflow si l’une ou l’autre des conditions suivantes est vraie :

• Les deux workflows se trouvent dans le même dépôt.
• Le flux de travail appelé est stocké dans un dépôt public, et votre enterprise vous permet d'utiliser des workflows publics réutilisables.
• Le workflow appelé est stocké dans un dépôt privé, et les paramètres définis pour ce dépôt le rendent accessible. Pour plus d’informations, consultez « Partage d’actions et de workflows au sein de votre entreprise ».

Le tableau suivant montre l’accessibilité des flux de travail réutilisables pour un flux de travail appelant, en fonction de la visibilité du référentiel hôte.

Référentiel appelant	Référentiels de flux de travail accessibles
private	private, internal, et public
internal	internal, et public
public	public

Les autorisations d’actions sur la page des paramètres Actions du référentiel appelant doivent être configurées pour autoriser l’utilisation d’actions et de flux de travail réutilisables. Consultez « Gestion des paramètres de GitHub Actions pour un dépôt ».

Pour les référentiels privés, la Stratégie d’accès sur la page Paramètres Actions du référentiel du flux de travail appelé doit être explicitement configurée pour autoriser l’accès à partir de référentiels contenant des flux de travail appelants - voir « Gestion des paramètres de GitHub Actions pour un dépôt ».

Limites

• Vous pouvez connecter jusqu’à quatre niveaux de workflows. Pour plus d’informations, consultez « Imbrication de flux de travail réutilisables ».

• Vous pouvez appeler un maximum de 20 workflows réutilisables à partir d’un fichier de workflow unique. Cette limite inclut toutes les arborescences de workflows réutilisables imbriqués qui peuvent être appelés à partir de votre fichier de workflows de l’appelant de niveau supérieur.

  Par exemple, workflow_appelant_niveau_supérieur.yml → workflow_appelé-1.yml → workflow_appelé-2.yml compte comme deux workflows réutilisables.

• Toutes les variables d’environnement configurées dans un contexte env défini au niveau du workflow dans le workflow appelant ne sont pas propagées au workflow appelé. Pour plus d’informations, consultez « Stocker des informations dans des variables » et « Référence sur les contextes ».

• De même, les variables d’environnement configurées dans le contexte env, défini dans le workflow appelé, ne sont pas accessibles dans le contexte env du workflow de l’appelant. Au lieu de cela, vous devez utiliser les sorties du workflow réutilisable. Pour plus d’informations, consultez « Utilisation de sorties à partir d’un flux de travail réutilisable ».

• Pour réutiliser des variables dans plusieurs workflows, définissez-les au niveau de l’organisation, du dépôt ou de l’environnement, et référencez-les à l’aide du contexte vars. Pour plus d’informations, consultez « Stocker des informations dans des variables » et « Référence sur les contextes ».

• Les workflows réutilisables sont appelés directement au sein d’un travail, et non à partir d’une étape de travail. Vous ne pouvez donc pas utiliser GITHUB_ENV pour passer des valeurs aux étapes de travail dans le workflow de l’appelant.

Mots clés pris en charge pour les travaux qui appellent un workflow réutilisable

Lorsque vous appelez un workflow réutilisable, vous ne pouvez utiliser que les mots clés suivants dans le travail contenant l’appel :

• jobs.<job_id>.name

• jobs.<job_id>.uses

• jobs.<job_id>.with

• jobs.<job_id>.with.<input_id>

• jobs.<job_id>.secrets

• jobs.<job_id>.secrets.<secret_id>

• jobs.<job_id>.secrets.inherit

• jobs.<job_id>.strategy

• jobs.<job_id>.needs

• jobs.<job_id>.if

• jobs.<job_id>.concurrency

• jobs.<job_id>.permissions

  Remarque

  • Si jobs.<job_id>.permissions n’est pas spécifié dans le travail appelant, le workflow appelé a les autorisations par défaut de GITHUB_TOKEN. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
  • Les autorisations GITHUB_TOKEN passées à partir du workflow appelant ne peuvent être rétrogradées (non élevées) que par le workflow appelé.
  • Si vous utilisez jobs.<job_id>.concurrency.cancel-in-progress: true, n’utilisez pas la même valeur pour jobs.<job_id>.concurrency.group les flux de travail appelés et appelants, car cela entraîne l’annulation du flux de travail déjà en cours d’exécution. Un flux de travail appelé utilise le nom du flux de travail appelant dans ${{ github.workflow }}, de sorte que l'utilisation de ce contexte comme valeur jobs.<job_id>.concurrency.group dans les flux de travail appelant et appelé entraînera l'annulation du workflow appelant lors de l'exécution du workflow appelé.

Comment les flux de travail réutilisables utilisent des exécuteurs

GitHub-a accueilli des exécuteurs

L’affectation d’exécuteurs hébergés par GitHub est toujours évaluée à l’aide du contexte de l’appelant uniquement. La facturation des exécuteurs hébergés par GitHub est toujours associée à l’appelant. Le workflow appelant ne peut pas utiliser des exécuteurs hébergés par GitHub à partir du dépôt appelé. Pour plus d’informations, consultez « GitHub-hosted runners ».

Exécuteurs auto-hébergés

Les workflows appelés qui appartiennent au même utilisateur ou à la même organisation ou entreprise que le workflow appelant peuvent accéder aux exécuteurs auto-hébergés à partir du contexte de l’appelant. Cela signifie qu’un workflow appelé peut accéder aux exécuteurs auto-hébergés qui se trouvent :

• Dans le dépôt appelant
• Dans l’organisation ou l’entreprise du dépôt appelant, à condition que l’exécuteur ait été mis à la disposition du dépôt appelant

Accès et autorisations pour les flux de travail imbriqués

Un workflow qui contient des workflows réutilisables imbriqués échouera si l’un des workflows imbriqués n’est pas accessible au workflow de l’appelant initial. Pour plus d’informations, consultez Accès aux workflows réutilisables.

Dans les workflows imbriqués, les autorisations GITHUB_TOKEN ne peuvent être identiques ni plus restrictives. Par exemple, dans la chaîne de workflows A > B > C, si le workflow A dispose d’une autorisation de jeton package: read, B et C ne peuvent pas avoir d’autorisation package: write. Pour plus d’informations, consultez « Use GITHUB_TOKEN for authentication in workflows ».

Pour plus d’informations sur l’utilisation de l’API pour déterminer quels fichiers de workflow ont été impliqués dans une exécution de workflow particulière, consultez Reuse workflows.

Comportement des flux de travail réutilisables lors de la réexécution des travaux

Les workflows réutilisables provenant de référentiels publics peuvent être référencés à l’aide d’un SHA, d’une étiquette de mise en production ou d’un nom de branche. Pour plus d’informations, consultez « Reuse workflows ».

Lorsque vous réexécutez un workflow qui utilise un workflow réutilisable et que la référence n’est pas un SHA, il existe des comportements à prendre en compte :

• La réexécution de tous les travaux dans un workflow utilise le workflow réutilisable à partir de la référence spécifiée. Pour plus d’informations sur la réexécution de tous les travaux d’un workflow, consultez Re-running workflows and jobs.
• La réexécution des travaux ayant échoué ou d’un travail spécifique dans un workflow utilise le workflow réutilisable à partir du même SHA de validation que lors de la première tentative. Pour plus d’informations sur la réexécution des travaux en échec d’un workflow, consultez Re-running workflows and jobs. Pour plus d’informations sur la réexécution d’un travail spécifique d’un workflow, consultez Re-running workflows and jobs.

Contexte github

Lorsqu’un workflow réutilisable est déclenché par un workflow appelant, le contexte github est toujours associé au workflow appelant. Le workflow appelé est automatiquement autorisé à accéder à github.token et à secrets.GITHUB_TOKEN. Pour plus d’informations sur le contexte github, consultez « Référence sur les contextes ».