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 workflows de démarrage permettent à tous les membres de votre organisation disposant de l’autorisation de créer des workflows de le faire plus rapidement et plus facilement. Quand vous créez un workflow, vous pouvez choisir un workflow de démarrage. Une partie ou la totalité du travail d’écriture du workflow est effectuée à votre place. Vous pouvez utiliser des workflows de démarrage comme point de départ pour créer votre workflow personnalisé, ou les utiliser en l’état. Cela permet non seulement de gagner du temps, mais également de promouvoir la cohérence et les bonnes pratiques dans l’ensemble de votre organisation.
GitHub fournit des workflows de démarrage prêts à l’emploi pour les catégories de haut niveau suivantes :
-
Déploiement (CD) . Pour plus d’informations, consultez « À propos du déploiement continu ».
-
Intégration continue (CI) . Pour plus d’informations, consultez « À propos de l’intégration continue ».
-
Automatisation. Les workflows de démarrage Automation offrent des solutions pour automatiser les workflows, comme le tri des demandes d’extraction et l’application d’une étiquette en fonction des chemins qui sont modifiés dans la demande de tirage ou des utilisateurs qui sont contributeurs au référentiel pour la première fois.
Création d’un workflow de démarrage
Les workflows de démarrage peuvent être créés par les utilisateurs disposant d’un accès en écriture au dépôt .github
de l’organisation. Ils peuvent ensuite être utilisés par les membres de l’organisation qui disposent de l’autorisation de créer des workflows.
Remarque : Pour éviter la duplication entre les workflows de démarrage, vous pouvez appeler des workflows réutilisables à partir d’un workflows. La gestion de vos workflows peut s’en trouver simplifiée. Pour plus d’informations, consultez « Réutilisation des workflows ».
Cette procédure montre comment créer un workflow de démarrage et un fichier de métadonnées. Le fichier de métadonnées décrit la façon dont les workflows de démarrage sont présentés aux utilisateurs lors de la création d’un workflow.
-
S’il n’existe pas encore, créez un dépôt public nommé
.github
dans votre organisation. -
Créez un répertoire nommé
workflow-templates
. -
Créez votre nouveau fichier de workflow dans le répertoire
workflow-templates
.Si vous devez faire référence à la branche par défaut d’un dépôt, vous pouvez utiliser l’espace réservé
$default-branch
. 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.
Remarque : les valeurs suivantes dans la clé runs-on
sont également traitées comme des espaces réservés :
- « ubuntu-latest » est remplacé par « [ auto-hébergé ] »
- « windows-latest » est remplacé par « [ auto-hébergé, windows ] »
- « ubuntu-latest » est remplacé par « [ auto-hébergé, macOS ] »
Par exemple, ce fichier nommé octo-organization-ci.yml
illustre un workflow de base.
name: Octo Organization CI on: push: branches: [ $default-branch ] pull_request: branches: [ $default-branch ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - 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@v4
- name: Run a one-line script
run: echo Hello from Octo Organization
-
Créez un fichier de métadonnées dans le répertoire
workflow-templates
. 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 starter workflow.", "iconName": "example-icon", "categories": [ "Go" ], "filePatterns": [ "package.json$", "^Dockerfile", ".*\\.md$" ] }
{ "name": "Octo Organization Workflow", "description": "Octo Organization CI starter workflow.", "iconName": "example-icon", "categories": [ "Go" ], "filePatterns": [ "package.json$", "^Dockerfile", ".*\\.md$" ] }
-
name
- Obligatoire. Nom du workflow. Celui-ci s’affiche dans la liste des workflows disponibles. -
description
- Obligatoire. 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. Les typesiconName
possibles sont les 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é commeexample-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
.
- Fichier SVG stocké dans le répertoire
-
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.
-
Pour ajouter un autre workflow de démarrage, ajoutez vos fichiers au même répertoire workflow-templates
.
Étapes suivantes
Pour continuer à découvrir GitHub Actions, consultez « Utilisation de workflows de démarrage ».