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
Les actions que vous utilisez dans votre workflow peuvent être définies dans :
- Le même dépôt que votre fichier de workflow
- Un dépôt interne dans le même compte d’entreprise configuré pour autoriser l’accès aux workflows
- Tout dépôt public
- Une image conteneur Docker publiée sur Docker Hub
GitHub Marketplace est un emplacement central où vous trouverez les actions créées par la communauté GitHub.
Remarque : GitHub Actions sur votre instance GitHub Enterprise Server peut avoir un accès limité aux actions sur GitHub.com ou GitHub Marketplace. Pour plus d’informations, consultez « Gestion de l’accès aux actions de GitHub.com » et contactez votre administrateur de site GitHub Enterprise.
Ajout d’une action à partir du même dépôt
Si une action est définie dans le même dépôt que celui où votre fichier de workflow utilise l’action, vous pouvez référencer l’action avec la syntaxe {owner}/{repo}@{ref}
ou ./path/to/dir
dans votre fichier de workflow.
Exemple de structure de fichier de dépôt :
|-- hello-world (repository)
| |__ .github
| └── workflows
| └── my-first-workflow.yml
| └── actions
| |__ hello-world-action
| └── action.yml
Le chemin d’accès relatif (./
) par rapport au répertoire de travail par défaut (github.workspace
, $GITHUB_WORKSPACE
). Si l’action extrait le référentiel d’un emplacement différent du flux de travail, le chemin d’accès relatif utilisé pour les actions locales doit être mis à jour.
Exemple de fichier de workflow :
jobs:
my_first_job:
runs-on: ubuntu-latest
steps:
# This step checks out a copy of your repository.
- name: My first step - check out repository
uses: actions/checkout@v4
# This step references the directory that contains the action.
- name: Use local hello-world-action
uses: ./.github/actions/hello-world-action
Le fichier action.yml
est utilisé pour fournir des métadonnées pour l’action. Découvrez le contenu de ce fichier dans « Metadata syntax for GitHub Actions ».
Ajout d’une action à partir d’un autre dépôt
Si une action est définie dans un autre dépôt que celui de votre fichier de workflow, vous pouvez référencer l’action avec la syntaxe {owner}/{repo}@{ref}
dans votre fichier de workflow.
L’action doit être stockée dans un dépôt public ou un dépôt interne configuré pour autoriser l’accès aux workflows. Pour plus d’informations, consultez « Partage d’actions et de workflows au sein de votre entreprise »
jobs:
my_first_job:
steps:
- name: My first step
uses: actions/setup-node@v4
Référencement d’un conteneur sur Docker Hub
Si une action est définie dans une image conteneur Docker publiée sur Docker Hub, vous devez référencer l’action avec la syntaxe docker://{image}:{tag}
dans votre fichier de workflow. Pour protéger votre code et vos données, nous vous recommandons vivement de vérifier l’intégrité de l’image conteneur Docker à partir de Docker Hub avant de l’utiliser dans votre workflow.
jobs:
my_first_job:
steps:
- name: My first step
uses: docker://alpine:3.8
Pour obtenir des exemples d’actions Docker, consultez le workflow Docker-image.yml et « Creating a Docker container action ».
Renforcement de la sécurité pour l’utilisation d’actions dans vos flux de travail
GitHub fournit des fonctionnalités de sécurité que vous pouvez utiliser pour augmenter la sécurité de vos flux de travail. Vous pouvez utiliser les fonctionnalités intégrées GitHub pour vous assurer que vous êtes informé des vulnérabilités dans les actions que vous consommez ou pour automatiser le processus d’actualisation des actions dans vos flux de travail. Pour plus d’informations, consultez « Utiliser les fonctions de sécurité de GitHub pour sécuriser votre utilisation des actions GitHub ».
Utilisation de la gestion des mises en production pour vos actions personnalisées
Les créateurs d’une action de communauté ont la possibilité d’utiliser des étiquettes, des branches ou des valeurs SHA pour gérer les mises en production de l’action. Comme pour toute dépendance, vous devez indiquer la version de l’action que vous souhaitez utiliser en fonction de votre confort avec l’acceptation automatique des mises à jour de l’action.
Vous désignerez la version de l’action dans votre fichier de workflow. Consultez la documentation de l’action pour obtenir des informations sur son approche de la gestion des mises en production et pour voir quelle balise, branche ou valeur SHA utiliser.
Remarque : Nous vous recommandons d’utiliser une valeur SHA lors de l’utilisation d’actions tierces. Cependant, il convient de noter que Dependabot ne créera Dependabot alerts que pour les GitHub Actions vulnérables qui utilisent le contrôle de version sémantique. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions » et « À propos des alertes Dependabot ».
Utilisation des étiquettes
Les étiquettes sont utiles pour vous permettre de décider quand basculer entre les versions principales et mineures, mais elles sont plus éphémères et peuvent être déplacées ou supprimées par le chargé de maintenance. Cet exemple montre comment cibler une action étiquetée v1.0.1
:
steps:
- uses: actions/javascript-action@v1.0.1
Utilisation des valeurs SHA
Si vous avez besoin d’un contrôle de versions plus fiable, vous devez utiliser la valeur SHA associée à la version de l’action. Les valeurs SHA sont immuables et, par conséquent, plus fiables que les étiquettes ou les branches. Toutefois, cette approche signifie que vous ne recevrez pas automatiquement les mises à jour pour une action, y compris les mises à jour de sécurité et les correctifs de bogues importants. Vous devez utiliser la valeur SHA complète d’un commit et non une valeur abrégée. Lorsque vous sélectionnez un SHA, vous devez vérifier qu’il provient du dépôt de l’action et non d’une fourche de dépôt. Cet exemple cible le SHA d’une action :
steps:
- uses: actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f
Utilisation des branches
La spécification d’une branche cible pour l’action signifie qu’elle exécutera toujours la version figurant actuellement sur cette branche. Cette approche peut créer des problèmes si une mise à jour de la branche inclut des changements cassants. Cet exemple cible une branche nommée @main
:
steps:
- uses: actions/javascript-action@main
Pour plus d’informations, consultez « À propos des actions personnalisées ».
Utilisation d’entrées et de sorties avec une action
Une action accepte ou nécessite souvent des entrées et génère des sorties que vous pouvez utiliser. Par exemple, une action peut exiger que vous spécifiiez un chemin d’accès à un fichier, le nom d’une étiquette ou d’autres données qu’elle utilisera dans le cadre du traitement de l’action.
Pour afficher les entrées et sorties d’une action, vérifiez action.yml
ou action.yaml
dans le répertoire racine du dépôt.
Dans cet exemple de fichier action.yml
, le mot clé inputs
définit une entrée obligatoire appelée file-path
et inclut une valeur par défaut qui sera utilisée si aucune valeur n’est spécifiée. Le mot clé outputs
définit une sortie appelée results-file
, qui vous indique où localiser les résultats.
name: "Example"
description: "Receives file and generates output"
inputs:
file-path: # id of input
description: "Path to test script"
required: true
default: "test-file.js"
outputs:
results-file: # id of output
description: "Path to results file"
Étapes suivantes
Pour continuer à découvrir GitHub Actions, consultez « Essential features of GitHub Actions ».