Parcourir les actions de la Place de marché dans l’éditeur de workflow
Vous pouvez rechercher des actions et les parcourir directement dans l’éditeur de workflow de votre dépôt. Dans la barre latérale, vous pouvez rechercher une action spécifique, afficher les actions proposées et parcourir les catégories proposées. Vous pouvez également voir le nombre d’étoiles qu’une action a reçu de la GitHub communauté.
- Dans votre dépôt, accédez au fichier de workflow que vous souhaitez modifier.
- Dans le coin supérieur droit de la vue de fichier, pour ouvrir l’éditeur de flux de travail, cliquez .

- À droite de l’éditeur, utilisez la GitHub Marketplace barre latérale pour parcourir les actions. Les actions avec le badge indiquent que GitHub a vérifié le créateur de l’action en tant qu’organisation partenaire.

Ajout d’une action à votre workflow
Vous pouvez ajouter une action à votre workflow en référençant l’action dans votre fichier de workflow. Les actions que vous utilisez dans votre workflow peuvent être définies dans :
- Le même dépôt que votre fichier de flux de travail
- Tout dépôt public
- Image conteneur Docker publiée sur Docker Hub
Vous pouvez afficher les actions référencées dans vos GitHub Actions flux de travail en tant que dépendances dans le graphique des dépendances du référentiel contenant vos flux de travail. Pour plus d’informations, consultez « Graphe de dépendances ».
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.
Ajout d’une action à partir de GitHub Marketplace
La page de référencement d’une action inclut la version de l’action et la syntaxe de workflow requises pour utiliser l’action. Pour maintenir votre workflow stable même lorsque des mises à jour sont apportées à une action, vous pouvez référencer la version de l’action à utiliser en spécifiant le numéro d’étiquette Git ou Docker dans votre fichier de workflow.
- Accédez à l’action que vous souhaitez utiliser dans votre workflow.
- Cliquez pour afficher la liste complète de la Place de marché pour l’action.
- Sous « Installation », cliquez pour copier la syntaxe du flux de travail.

- Collez la syntaxe en tant que nouvelle étape dans votre workflow. Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».
- Si l’action vous oblige à fournir des entrées, définissez-les dans votre workflow. Pour obtenir des informations sur les entrées qu’une action peut nécessiter, consultez « Utilisation de blocs élémentaires pré-écrits dans votre workflow ».
Vous pouvez également activer Dependabot version updates pour les actions que vous ajoutez à votre flux de travail. Pour plus d’informations, consultez « Maintenir vos actions à jour avec Dependabot ».
Ajout d’une action à partir du même dépôt
Si une action est définie dans le même référentiel que celui où votre fichier de flux de travail utilise l’action, vous pouvez référencer l’action avec la $/path/to/dir référence de dépôt automatique, ou avec la syntaxe ou ./path/to/dir la {owner}/{repo}@{ref} syntaxe dans votre fichier de flux de travail. La $/ syntaxe n’est pas disponible dans GitHub Enterprise Server.
Exemple de structure de fichier de dépôt :
|-- hello-world (repository)
| |__ .github
| └── workflows
| └── my-first-workflow.yml
| └── actions
| |__ hello-world-action
| └── action.yml
Nous vous recommandons de référencer l’action avec la $/path/to/dir référence de référentiel automatique. Cela se résout vers le même référentiel au niveau de la validation en cours d’exécution. Vous n’avez donc pas besoin d’extraire d’abord le référentiel. Pour plus d’informations sur la façon dont $/ les comparaisons sont à {owner}/{repo}@{ref} et ./, consultez Syntaxe de flux de travail pour GitHub Actions.
Exemple de fichier de flux de travail à l’aide $/de :
jobs:
my_first_job:
runs-on: ubuntu-latest
steps:
# This step references an action in the same repository at the
# running commit. No repository checkout is required.
- name: Use hello-world-action
uses: $/.github/actions/hello-world-action
Vous pouvez également référencer l’action avec la syntaxe relative ./path/to/dir , mais elle est plus sujette aux erreurs. Le chemin d’accès est relatif (./) au répertoire de travail par défaut (github.workspace, ), $GITHUB_WORKSPACEil nécessite donc une étape d’extraction et si l’action extrait le référentiel à un emplacement différent du flux de travail, le chemin relatif doit être mis à jour.
Exemple de fichier de flux de travail à l’aide ./de :
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@v6
# 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 « Référence syntaxique des métadonnées ».
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 référentiel.
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 flux de travail. Pour protéger votre code et vos données, nous vous recommandons vivement de vérifier l’intégrité de l’image conteneur Docker de Docker Hub avant de l’utiliser dans votre flux de travail.
jobs:
my_first_job:
steps:
- name: My first step
uses: docker://alpine:3.8
Pour obtenir des exemples d’actions Docker, consultez le flux de travail Docker-image.yml et « Création d’une action de conteneur Docker ».
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 renforcer la sécurité de vos flux de travail. Vous pouvez utiliser GitHubles fonctionnalités intégrées pour vous assurer que vous êtes informé des vulnérabilités dans les actions que vous consommez ou pour automatiser le processus de conservation des actions dans vos flux de travail. Pour plus d’informations, consultez « Informations de référence sur l’utilisation sécurisée ».
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. Toutefois, il est important de noter que Dependabot ne créera Dependabot alerts que pour les GitHub Actions vulnérables qui utilisent le versionnage sémantique. Pour plus d’informations, consultez « Informations de référence sur l’utilisation sécurisée » et « 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 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 la 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 « Gestion 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 dans le répertoire racine du référentiel.
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"