Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.
Vue d’ensemble
Au lieu de copier et de coller d’un workflow vers un autre, vous pouvez rendre les workflows réutilisables. Vous et toute personne ayant accès au workflow réutilisable peut alors appeler le workflow réutilisable à partir d’un autre workflow.
La réutilisation de workflows évite la duplication. Cela facilite la maintenance des workflows et vous permet de créer plus rapidement de nouveaux workflows en s’appuyant sur le travail des autres, comme vous le faites avec des actions. La réutilisation des workflows favorise également les bonnes pratiques en vous aidant à utiliser des workflows bien conçus, qui ont déjà été testés et qui se sont avérés efficaces. Votre organisation peut créer une bibliothèque de workflows réutilisables qui peuvent être gérés de manière centralisée.
Le diagramme ci-dessous montre une exécution de flux de travail en cours qui utilise un workflow réutilisable.
- Une fois que chacun des trois travaux de build à gauche du diagramme se termine avec succès, un travail dépendant appelé « Déployer » est exécuté.
- Le travail « Déployer » appelle un workflow réutilisable qui contient trois travaux : « Préproduction », « Révision » et « Production ».
- Le travail de déploiement « Production » s’exécute uniquement une fois que le travail « Préproduction » s’est correctement terminé.
- Quand un travail cible un environnement, l’exécution du workflow affiche une barre de progression qui indique le nombre d’étapes du travail. Dans le diagramme ci-dessous, le travail « Production » contient 8 étapes, l’étape 6 étant en cours de traitement.
- L’utilisation d’un workflow réutilisable pour exécuter des travaux de déploiement vous permet d’exécuter ces travaux pour chaque build sans dupliquer du code dans les workflows.
Un workflow qui utilise un autre workflow est appelé workflow « appelant ». Le workflow réutilisable est workflow « appelé ». Un workflow appelant peut utiliser plusieurs workflows appelés. Chaque workflow appelé est référencé sur une seule ligne. Le résultat est que le workflow appelant peut ne contenir que quelques lignes de code YAML, mais effectuer un grand nombre de tâches quand il est exécuté. Lorsque vous réutilisez un workflow, l’ensemble du workflow appelé est utilisé, comme s’il faisait partie du workflow appelant.
Si vous réutilisez un workflow d’un autre dépôt, toutes les actions du workflow appelé s’exécutent comme si elles faisaient partie du workflow appelant. Par exemple, si le workflow appelé utilise actions/checkout
, l’action extrait le contenu du dépôt qui héberge le workflow appelant, et non le workflow appelé.
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 « Accès à des informations contextuelles sur l’exécution d’un workflow ».
Vous pouvez afficher les workflows réutilisés référencés dans vos workflows GitHub Actions en tant que dépendances dans le graphique des dépendances du dépôt contenant vos workflows. Pour plus d’informations, consultez « À propos du graphique des dépendances ».
Flux de travail réutilisables et actions composites
Les flux de travail réutilisables et les actions composites vous aident à éviter la duplication. Alors que les flux de travail réutilisables vous permettent de réutiliser un flux de travail entier, avec plusieurs travaux et étapes, les actions composites combinent plusieurs étapes que vous pouvez ensuite exécuter dans une étape de travail, comme toute autre action. Pour plus d’informations, consultez « Prévention de la duplication ».
Workflows réutilisables et modèles de workflow
Les modèles de workflow permettent à tous les membres de votre organisation disposant de l’autorisation de créer des workflows de le faire plus rapidement et plus facilement. Lorsque les utilisateurs créent un nouveau workflow, ils peuvent choisir un modèle de workflow et une partie ou la totalité du travail d’écriture du workflow sera effectuée pour eux. Dans un modèle de workflow, vous pouvez également référencer des workflows réutilisables afin de faciliter la réutilisation du code de workflow géré de manière centralisée. Si vous utilisez un SHA de commit lors du référencement du workflow réutilisable, vous garantissez que tous ceux qui réutilisent ce workflow utiliseront toujours le même code YAML. Toutefois, si vous référencez un workflow réutilisable par une étiquette ou une branche, assurez-vous que vous pouvez approuver cette version du workflow. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».
Pour plus d’informations, consultez « Création de modèles de workflow pour votre organisation ».
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 sur GitHub Enterprise Server.
Vous ne pouvez pas utiliser directement les flux de travail réutilisables définis sur GitHub.com. Au lieu de cela, stockez une copie du flux de travail réutilisable sur votre instance GitHub Enterprise Server, et appelez le flux de travail à 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 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 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 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 - voir « Gestion des paramètres de GitHub Actions pour un dépôt ».
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.
Utilisation des exécuteurs
Utilisation des exécuteurs hébergés par GitHub
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 « Utilisation des exécuteurs hébergés par GitHub ».
Utilisation des 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
Limites
-
Vous pouvez connecter jusqu’à quatre niveaux de workflows. Pour plus d’informations, consultez « Imbrication de workflows 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 « Accès à des informations contextuelles sur l’exécution d’un workflow ». -
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 contexteenv
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 « Accès à des informations contextuelles sur l’exécution d’un workflow ». -
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.
Création d’un workflow réutilisable
Les workflows réutilisables sont des fichiers au format YAML, très similaires à tout autre fichier de workflow. Comme avec d’autres fichiers de workflow, vous localisez les workflows réutilisables dans le répertoire .github/workflows
d’un dépôt. Les sous-répertoires du répertoire workflows
ne sont pas pris en charge.
Pour qu’un workflow soit réutilisable, les valeurs de on
devront inclure workflow_call
:
on:
workflow_call:
Utilisation d’entrées et de secrets dans un workflow réutilisable
Vous pouvez définir des entrées et des secrets, qui peuvent être passés à partir du workflow appelant, puis utilisés dans le workflow appelé. L’utiliser d’une entrée ou d’un secret dans un workflow réutilisable comporte trois étapes.
-
Dans le workflow réutilisable, utilisez les mots clés
inputs
etsecrets
pour définir des entrées ou des secrets qui seront passés à partir d’un workflow appelant.on: workflow_call: inputs: config-path: required: true type: string secrets: personal_access_token: required: true
Pour obtenir des détails sur la syntaxe de la définition d’entrées et de secrets, consultez on.workflow_call.inputs
et on.workflow_call.secrets
.
-
Dans le workflow réutilisable, référencez l’entrée ou le secret que vous avez défini(e) dans la clé
on
à l’étape précédente.Remarque :Si les secrets sont hérités par l’utilisation de
secrets: inherit
dans le workflow d’appel, vous pouvez les référencer même s’ils ne sont pas définis explicitement dans la cléon
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».jobs: reusable_workflow_job: runs-on: ubuntu-latest steps: - uses: actions/labeler@v4 with: repo-token: ${{ secrets.personal_access_token }} configuration-path: ${{ inputs.config-path }}
Dans l’exemple ci-dessus,
personal_access_token
est un secret défini au niveau du référentiel ou de l’organisation.Avertissement : les secrets d’environnement ne peuvent pas être transmis à partir du workflow de l’appelant, car
on.workflow_call
ne prend pas en charge le mot cléenvironment
. Si vous incluezenvironment
dans le workflow réutilisable au niveau de la tâche, le secret d’environnement sera utilisé et non le secret transmis à partir du workflow de l’appelant. Pour plus d’informations, consultez « Gestion des environnements pour le déploiement » et « Workflow syntax for GitHub Actions ». -
Passez l’entrée ou le secret à partir du workflow appelant.
Pour transmettre des entrées nommées à un workflow appelé, utilisez le mot clé
with
dans un travail. Utilisez le mot clésecrets
pour transmettre des secrets nommés. Pour les entrées, le type de données de la valeur d’entrée doit correspondre au type spécifié dans le workflow appelé (booléen, nombre ou chaîne).jobs: call-workflow-passing-data: uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main with: config-path: .github/labeler.yml secrets: personal_access_token: ${{ secrets.token }}
Les workflows qui appellent des workflows réutilisables dans la même organisation ou entreprise peuvent utiliser le mot clé
inherit
pour transmettre implicitement les secrets.jobs: call-workflow-passing-data: uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main with: config-path: .github/labeler.yml secrets: inherit
Exemple de workflow réutilisable
Ce fichier de workflow réutilisable nommé workflow-B.yml
(auquel nous ferons référence plus tard dans l’exemple de workflow appelant) prend une chaîne d’entrée et un secret provenant du workflow appelant et les utilise dans une action.
name: Reusable workflow example on: workflow_call: inputs: config-path: required: true type: string secrets: token: required: true jobs: triage: runs-on: ubuntu-latest steps: - uses: actions/labeler@v4 with: repo-token: ${{ secrets.token }} configuration-path: ${{ inputs.config-path }}
name: Reusable workflow example
on:
workflow_call:
inputs:
config-path:
required: true
type: string
secrets:
token:
required: true
jobs:
triage:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v4
with:
repo-token: ${{ secrets.token }}
configuration-path: ${{ inputs.config-path }}
Appel d’un workflow réutilisable
Vous appelez un workflow réutilisable à l’aide du mot clé uses
. Contrairement à l’étape dans laquelle vous utilisez des actions dans un workflow, vous appelez des workflows réutilisables directement au sein d’un travail, et non à partir d’étapes de travail.
Pour référencer des fichiers de workflow réutilisables, utilisez l’une des syntaxes suivantes :
{owner}/{repo}/.github/workflows/{filename}@{ref}
pour les flux de travail réutilisables dans les dépôts publics, internes et privés../.github/workflows/{filename}
pour des workflows réutilisables dans le même dépôt.
Dans la première options, {ref}
peut être un SHA, une étiquette de mise en production ou un nom de branche. Si une balise de mise en production et une branche portent le même nom, la balise de mise en production est prioritaire sur le nom de la branche. L’utilisation du SHA de validation est l’option la plus sûre pour la stabilité et la sécurité. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».
Si vous utilisez la deuxième option de syntaxe (sans {owner}/{repo}
et @{ref}
), le workflow appelé provient du même commit que le workflow appelant. Les préfixes ref tels que refs/heads
et refs/tags
ne sont pas autorisés. Vous ne pouvez pas utiliser de contextes ou d’expressions dans ce mot clé.
Vous pouvez appeler plusieurs workflows, en référençant chacun dans un travail distinct.
jobs:
call-workflow-1-in-local-repo:
uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89
call-workflow-2-in-local-repo:
uses: ./.github/workflows/workflow-2.yml
call-workflow-in-another-repo:
uses: octo-org/another-repo/.github/workflows/workflow.yml@v1
Passage d’entrées et de secrets à un workflow réutilisable
Pour transmettre des entrées nommées à un workflow appelé, utilisez le mot clé with
dans un travail. Utilisez le mot clé secrets
pour transmettre des secrets nommés. Pour les entrées, le type de données de la valeur d’entrée doit correspondre au type spécifié dans le workflow appelé (booléen, nombre ou chaîne).
jobs:
call-workflow-passing-data:
uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
with:
config-path: .github/labeler.yml
secrets:
personal_access_token: ${{ secrets.token }}
Les workflows qui appellent des workflows réutilisables dans la même organisation ou entreprise peuvent utiliser le mot clé inherit
pour transmettre implicitement les secrets.
jobs:
call-workflow-passing-data:
uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
with:
config-path: .github/labeler.yml
secrets: inherit
Utilisation d’une stratégie de matrice avec un workflow réutilisable
Les travaux qui utilisent la stratégie de matrice peuvent appeler un workflow réutilisable.
Une stratégie de matrice vous permet d’utiliser des variables dans une définition de travail unique pour créer automatiquement plusieurs exécutions de travaux basées sur les combinaisons des variables. Par exemple, vous pouvez utiliser une stratégie de matrice pour passer différentes entrées à un workflow réutilisable. Pour plus d’informations sur les matrices, consultez « Exécution de variantes de tâches dans un workflow ».
Cet exemple de travail ci-dessous appelle un workflow réutilisable et fait référence au contexte de matrice en définissant la variable target
avec les valeurs [dev, stage, prod]
. Il va exécuter trois travaux, un pour chaque valeur de la variable.
jobs: ReuseableMatrixJobForDeployment: strategy: matrix: target: [dev, stage, prod] uses: octocat/octo-repo/.github/workflows/deployment.yml@main with: target: ${{ matrix.target }}
jobs:
ReuseableMatrixJobForDeployment:
strategy:
matrix:
target: [dev, stage, prod]
uses: octocat/octo-repo/.github/workflows/deployment.yml@main
with:
target: ${{ matrix.target }}
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 :
-
Remarque :
- Si
jobs.<job_id>.permissions
n’est pas spécifié dans le travail appelant, le workflow appelé a les autorisations par défaut deGITHUB_TOKEN
. Pour plus d’informations, consultez « Authentification par jeton automatique ». - 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 pourjobs.<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 valeurjobs.<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é.
- Si
Exemple de workflow appelant
Ce fichier de workflow appelle deux fichiers de workflow. Une entrée (config-path
) et un secret (token
) sont passés au deuxième de ces fichiers, workflow-B.yml
(illustré dans l’exemple de workflow réutilisable).
name: Call a reusable workflow on: pull_request: branches: - main jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1 call-workflow-passing-data: permissions: contents: read pull-requests: write uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main with: config-path: .github/labeler.yml secrets: token: ${{ secrets.GITHUB_TOKEN }}
name: Call a reusable workflow
on:
pull_request:
branches:
- main
jobs:
call-workflow:
uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1
call-workflow-passing-data:
permissions:
contents: read
pull-requests: write
uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main
with:
config-path: .github/labeler.yml
secrets:
token: ${{ secrets.GITHUB_TOKEN }}
Imbrication des workflows réutilisables
Vous pouvez connecter un maximum de quatre niveaux de workflows, c’est-à-dire le workflow de l’appelant de niveau supérieur et jusqu’à trois niveaux de workflows réutilisables. Par exemple : caller-workflow.yml → called-workflow-1.yml → called-workflow-2.yml → called-workflow-3.yml. Les boucles ne sont pas autorisées dans l’arborescence de workflows.
À partir d’un workflow réutilisable, vous pouvez appeler un autre workflow réutilisable.
name: Reusable workflow on: workflow_call: jobs: call-another-reusable: uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1
name: Reusable workflow
on:
workflow_call:
jobs:
call-another-reusable:
uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1
Passage de secrets à des workflows imbriqués
Vous pouvez utiliser jobs.<job_id>.secrets
dans un workflow appelant pour passer des secrets nommés à un workflow appelé directement. Vous pouvez également utiliser jobs.<job_id>.secrets.inherit
pour passer tous les secrets du workflow appelant à un workflow directement appelé. Pour plus d’informations, consultez la section « Réutilisation des workflows » ci-dessus et l’article de référence « Workflow syntax for GitHub Actions ». Les secrets sont passés uniquement au workflow appelé directement, de sorte que dans la chaîne de workflow A > B > C, le workflow C ne reçoit les secrets de A que s’ils ont été passés de A à B, puis de B à C.
Dans l’exemple suivant, le workflow A passe tous ses secrets au workflow B à l’aide du mot clé inherit
, mais le workflow B ne passe qu’un seul secret au workflow C. Les autres secrets passés au workflow B ne sont pas disponibles pour le workflow C.
jobs:
workflowA-calls-workflowB:
uses: octo-org/example-repo/.github/workflows/B.yml@main
secrets: inherit # pass all secrets
jobs:
workflowB-calls-workflowC:
uses: different-org/example-repo/.github/workflows/C.yml@main
secrets:
repo-token: ${{ secrets.personal_access_token }} # pass just this secret
Accès et autorisations
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 « Réutilisation des workflows ».
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 « Authentification par jeton automatique ».
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 « Supervision des workflows qui ont été utilisés ».
Utilisation de sorties à partir d’un workflow réutilisable
Un workflow réutilisable peut générer des données que vous souhaitez utiliser dans le workflow appelant. Pour utiliser ces sorties, vous devez les spécifier comme sorties du workflow réutilisable.
Si un workflow réutilisable qui définit une sortie est exécuté avec une stratégie de matrice, la sortie sera celle qui est définie par le dernier workflow réutilisable réussi de la matrice qui définit réellement une valeur. Cela signifie que si le dernier workflow réutilisable réussi définit une chaîne vide pour sa sortie et que l’avant-dernier workflow réutilisable réussi définit une valeur réelle pour sa sortie, la sortie contiendra la valeur de l’avant-dernier workflow réutilisable.
Le workflow réutilisable suivant comprend un seul travail contenant deux étapes. Dans chacune de ces étapes, nous définissons un mot unique comme sortie : « hello » et « world ». Dans la section outputs
du travail, nous mappons ces sorties d’étape aux sorties de travail appelées output1
et output2
. Dans la section on.workflow_call.outputs
, nous définissons ensuite deux sorties pour le workflow lui-même : une appelée firstword
que nous mappons à output1
, et l’autre appelée secondword
que nous mappons à output2
.
La valeur value
doit être définie sur une sortie au niveau du travail dans le flux de travail appelé. Les sorties au niveau de l’étape doivent d’abord être mappées aux sorties au niveau du travail, comme indiqué ci-dessous.
Pour plus d’informations, consultez « Transmission d’informations entre les travaux » et « Workflow syntax for GitHub Actions ».
name: Reusable workflow on: workflow_call: # Map the workflow outputs to job outputs outputs: firstword: description: "The first output string" value: ${{ jobs.example_job.outputs.output1 }} secondword: description: "The second output string" value: ${{ jobs.example_job.outputs.output2 }} jobs: example_job: name: Generate output runs-on: ubuntu-latest # Map the job outputs to step outputs outputs: output1: ${{ steps.step1.outputs.firstword }} output2: ${{ steps.step2.outputs.secondword }} steps: - id: step1 run: echo "firstword=hello" >> $GITHUB_OUTPUT - id: step2 run: echo "secondword=world" >> $GITHUB_OUTPUT
name: Reusable workflow
on:
workflow_call:
# Map the workflow outputs to job outputs
outputs:
firstword:
description: "The first output string"
value: ${{ jobs.example_job.outputs.output1 }}
secondword:
description: "The second output string"
value: ${{ jobs.example_job.outputs.output2 }}
jobs:
example_job:
name: Generate output
runs-on: ubuntu-latest
# Map the job outputs to step outputs
outputs:
output1: ${{ steps.step1.outputs.firstword }}
output2: ${{ steps.step2.outputs.secondword }}
steps:
- id: step1
run: echo "firstword=hello" >> $GITHUB_OUTPUT
- id: step2
run: echo "secondword=world" >> $GITHUB_OUTPUT
Nous pouvons maintenant utiliser les sorties dans le workflow appelant, de la même façon que vous utiliseriez les sorties d’un travail au sein du même workflow. Nous faisons référence aux sorties à l’aide des noms définis au niveau du workflow dans le workflow réutilisable : firstword
et secondword
. Dans ce workflow, job1
appelle le workflow réutilisable et job2
imprime les sorties de ce dernier (« hello world ») dans la sortie standard dans le journal du workflow.
name: Call a reusable workflow and use its outputs on: workflow_dispatch: jobs: job1: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1 job2: runs-on: ubuntu-latest needs: job1 steps: - run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}
name: Call a reusable workflow and use its outputs
on:
workflow_dispatch:
jobs:
job1:
uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}
Pour plus d’informations sur l’utilisation des sorties de travail, consultez « Workflow syntax for GitHub Actions ». Si vous souhaitez partager quelque chose d’autre qu’une variable (par exemple, un artefact de build) entre les workflows, consultez « Stockage et partage des données d’un workflow ».
Monitoring des workflows en cours d’utilisation
Vous pouvez utiliser l’API REST GitHub pour superviser la façon dont les workflows réutilisables sont utilisés. L’action de journal d’audit prepared_workflow_job
est déclenchée lors du démarrage d’un travail de workflow. Les données enregistrées sont les suivantes :
-
repo
: organisation/dépôt où se trouve le travail de workflow. Pour un travail qui appelle un autre workflow, il s’agit de l’organisation/du dépôt du workflow appelant. -
@timestamp
: date et heure de démarrage du travail, au format Unix Epoch. -
job_name
: nom du travail qui a été exécuté. -
calling_workflow_refs
- un tableau de chemins de fichiers pour tous les workflows de l’appelant impliqués dans ce travail de workflow. Les éléments du tableau sont dans l’ordre inverse de celui où ils ont été appelés. Par exemple, dans une chaîne de workflows A > B > C, lors de l’affichage des journaux pour un travail dans le workflow C, le tableau est["octo-org/octo-repo/.github/workflows/B.yml", "octo-org/octo-repo/.github/workflows/A.yml"]
. -
calling_workflow_shas
- un tableau de SHA pour tous les workflows de l’appelant impliqués dans ce travail de workflow. Le tableau contient le même nombre d’éléments, dans le même ordre, que le tableaucalling_workflow_refs
. -
job_workflow_ref
: fichier de workflow qui a été utilisé, sous la forme{owner}/{repo}/{path}/{filename}@{ref}
. Pour un travail qui appelle un autre workflow, cela identifie le workflow appelé.
Pour plus d’informations sur l’utilisation de l’API REST en vue d’interroger le journal d’audit d’une organisation, consultez « Points de terminaison d’API REST pour les organisations ».
Remarque : Les données d’audit pour prepared_workflow_job
ne peuvent être consultées qu’à l’aide de l’API REST. Elles ne sont pas visibles dans l’interface web GitHub, ni incluses dans les données d’audit exportées JSON/CSV.
Réexécution de workflows et de travaux avec des workflows réutilisables
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 « Réutilisation des 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 « Ré-exécution de workflows et de travaux ».
- 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 « Ré-exécution de workflows et de travaux ». Pour plus d’informations sur la réexécution d’un travail spécifique d’un workflow, consultez « Ré-exécution de workflows et de travaux ».
Étapes suivantes
Pour continuer à découvrir GitHub Actions, consultez « Événements qui déclenchent des flux de travail ».
Vous pouvez standardiser les déploiements en créant un groupe d’exécuteurs autohébergés qui peut uniquement exécuter un workflow réutilisable spécifique. Pour plus d’informations, consultez « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes ».