Réutilisation des configurations de flux de travail

Workflows réutilisables

Informations de référence sur les 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 workflow appelé est stocké dans un référentiel public sur GitHub Enterprise Server.

Il n’est pas possible d’utiliser directement les workflows réutilisables définis sur GitHub.com. Stockez plutôt une copie du workflow réutilisable sur votre instance GitHub Enterprise Server et appelez le workflow à partir de ce chemin.
Le workflow appelé est stocké dans un dépôt interne 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 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 présente l’accessibilité des workflows réutilisables à un workflow appelant, en fonction de la visibilité du référentiel hôte.

Référentiel appelant	Référentiels de workflows accessibles
`private`	Inclut `private`, `internal`, et `public`
`internal`

          `internal` et `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 référentiel.

Pour les référentiels internes ou 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. ConsultezGestion des paramètres de GitHub Actions pour un référentiel.

Remarque

Pour améliorer la sécurité, GitHub Actions ne prend pas en charge les redirections pour les actions ou les workflows réutilisables. Cela signifie que quand le propriétaire, le nom du dépôt d’une action ou le nom d’une action est modifié, tous les workflows utilisant cette action avec le nom précédent vont échouer.

Limitations des flux de travail réutilisables

Vous pouvez connecter jusqu’à quatre niveaux de flux de travail. Pour plus d’informations, consultez Imbrication de workflows réutilisables.
Vous pouvez appeler un maximum de 20 flux de travail réutilisables uniques à partir d’un seul fichier de flux de travail. 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 des 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 des résultats d’un workflow 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 des 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 « Syntaxe de flux de travail pour 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 dans les workflows appelés et appelants, car cela entraînerait l’annulation du workflow déjà en cours d’exécution. Un workflow appelé utilise le nom de son workflow appelant dans ${{ github.workflow }}. Par conséquent, l’utilisation de ce contexte comme valeur de jobs.<job_id>.concurrency.group dans les workflows appelant et appelé entraînera l’annulation du workflow appelant lors de l’exécution du workflow appelé.

Comment les workflows réutilisables utilisent les runners

GitHub : runners hébergés

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 « Exécuteurs hébergés par GitHub ».

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 workflows 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 « [AUTOTITLE](/actions/security-guides/automatic-token-authentication) ».

Pour plus d’informations sur la manière d’utiliser l’API afin de déterminer quels fichiers de workflow ont été impliqués dans une exécution de workflow particulière, consultez Réutiliser des workflows.

Comportement des workflows réutilisables lors de la réexécution de tâches

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 des contextes ».

Modèles de flux de travail

Informations de référence à utiliser lors de la création de modèles de flux de travail pour votre organisation.

Disponibilité des modèles de flux de travail

Vous pouvez utiliser des modèles dans des référentiels qui correspondent ou ont une visibilité plus restreinte que le référentiel de modèles.

Les modèles de flux de travail dans un référentiel public .github sont disponibles pour tous les types de référentiels.
Les modèles de flux de travail dans un référentiel interne .github ne sont disponibles que pour les référentiels internes et privés.
Les modèles de flux de travail dans un référentiel privé .github ne sont disponibles que pour les référentiels privés.

Accorder l’accès aux référentiels privés/internes

Si vous utilisez un référentiel .github privé ou interne, vous devez accorder un accès en lecture aux utilisateurs ou aux équipes qui doivent pouvoir utiliser les modèles.

Espace réservé `$default-branch`

Si vous devez faire référence à la branche par défaut d’un référentiel, vous pouvez utiliser l’espace réservé $default-branch dans votre modèle de flux de travail. Lorsqu’un workflow est créé, l’espace réservé est automatiquement remplacé par le nom de la branche par défaut du dépôt.

Valeurs d’espace réservé dans la clé `runs-on`

Les valeurs suivantes dans la clé runs-on sont également traitées comme des espaces réservés :

        `ubuntu-latest` est remplacé par `[ self-hosted ]`

        `windows-latest` est remplacé par `[ self-hosted, windows ]`

        `macos-latest"` est remplacé par `[ self-hosted, macOS ]`

Exemple de fichier de modèle de flux de travail

Ce fichier nommé octo-organization-ci.yml illustre un flux de travail de base.

YAML

name: Octo Organization CI
on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Run a one-line script
        run: echo Hello from Octo Organization

name: Octo Organization CI
on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Run a one-line script
        run: echo Hello from Octo Organization

Exigences relatives aux fichiers de métadonnées

Le fichier de métadonnées doit porter le même nom que le fichier de workflow, mais au lieu de l’extension .yml, l’extension .properties.json doit lui être ajoutée. Par exemple, ce fichier nommé octo-organization-ci.properties.json contient les métadonnées d’un fichier de workflow nommé octo-organization-ci.yml :

JSON

{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

        `name`
         - 
        **Requis.** Nom du workflow. Celui-ci s’affiche dans la liste des workflows disponibles.

        `description`
         - 
        **Requis.** Description du workflow. Celui-ci s’affiche dans la liste des workflows disponibles.

```
        `iconName`
         - 
        **Facultatif.** Spécifie une icône pour le workflow affiché dans la liste des workflows. 
        `iconName` peut être l’un des types suivants :
```
- Fichier SVG stocké dans le répertoire workflow-templates. Pour référencer un fichier, la valeur doit être le nom du fichier sans son extension. Par exemple, un fichier SVG nommé example-icon.svg est référencé comme example-icon .
- Icône de l’ensemble d’octicons de GitHub. Pour référencer un octicon, la valeur doit être octicon <icon name>. Par exemple : octicon smiley.

        `categories`
         - 
        **Facultatif.** Définit les catégories sous lesquelles le workflow est affiché. Vous pouvez utiliser des noms de catégorie à partir des listes suivantes :

Noms de catégorie généraux du dépôt starter-workflows.
Langages Linguist figurant dans la liste du dépôt linguist.
Piles techniques prises en charge figurant dans la liste du dépôt starter-workflows.

        `filePatterns`
         - 
        **Facultatif.** Permet d’utiliser le workflow si le dépôt de l’utilisateur a dans son répertoire racine un fichier qui correspond à une expression régulière définie.

Dans cet article