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.
Présentation des exemples
Cet article utilise un exemple de workflow pour illustrer certaines des principales fonctionnalités CI de GitHub Actions. Quand ce workflow est déclenché, il teste votre code à l’aide d’une matrice de combinaisons de test avec npm test
.
Le diagramme suivant montre une vue générale des étapes du workflow et comment elles s’exécutent dans le travail :
Fonctionnalités utilisées dans cet exemple
L’exemple de workflow illustre les fonctionnalités suivantes de GitHub Actions.
Fonctionnalité | Implémentation |
---|---|
Exécution manuelle d’un workflow à partir de l’interface utilisateur | workflow_dispatch |
Déclenchement de l’exécution automatique d’un workflow | pull_request |
Exécution d’un workflow à intervalles réguliers : | schedule |
Définition des autorisations pour le jeton | permissions |
Contrôle du nombre d’exécutions de workflow ou de travaux pouvant s’exécuter en même temps | concurrency |
Exécution du travail sur différents exécuteurs, selon le dépôt | runs-on |
Utilisation d’une matrice pour créer différentes configurations de test | matrix |
Installation de node sur l’exécuteur : | actions/setup-node |
Mise en cache des dépendances | actions/cache |
Exécution de tests sur l’exécuteur | npm test |
Exemple de flux de travail
Le workflow suivant a été créé par l’équipe Ingénierie de documents GitHub. Pour consulter la dernière version de ce fichier dans le référentiel github/docs
, consultez test.yml
.
Remarque : Chaque ligne de ce workflow est expliquée dans la section suivante, dans « Comprendre l’exemple ».
name: Node.js Tests
# **What it does**: Runs our tests.
# **Why we have it**: We want our tests to pass before merging code.
# **Who does it impact**: Docs engineering, open-source engineering contributors.
on:
workflow_dispatch:
pull_request:
push:
branches:
- main
permissions:
contents: read
# Needed for the 'trilom/file-changes-action' action
pull-requests: read
# This allows a subsequently queued workflow run to interrupt previous runs
concurrency:
group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
cancel-in-progress: true
jobs:
test:
# Run on self-hosted if the private repo or ubuntu-latest if the public repo
# See pull # 17442 in the private repo for context
runs-on: ${{ fromJSON('["ubuntu-latest", "self-hosted"]')[github.repository == 'github/docs-internal'] }}
timeout-minutes: 60
strategy:
fail-fast: false
matrix:
# The same array lives in test-windows.yml, so make any updates there too.
test-group:
[
content,
graphql,
meta,
rendering,
routing,
unit,
linting,
translations,
]
steps:
# Each of these ifs needs to be repeated at each step to make sure the required check still runs
# Even if if doesn't do anything
- name: Check out repo
uses: actions/checkout@v3
with:
# Not all test suites need the LFS files. So instead, we opt to
# NOT clone them initially and instead, include them manually
# only for the test groups that we know need the files.
lfs: ${{ matrix.test-group == 'content' }}
# Enables cloning the Early Access repo later with the relevant personal access token
persist-credentials: 'false'
- name: Figure out which docs-early-access branch to checkout, if internal repo
if: ${{ github.repository == 'github/docs-internal' }}
id: check-early-access
uses: actions/github-script@v6
env:
BRANCH_NAME: ${{ github.head_ref || github.ref_name }}
with:
github-token: ${{ secrets.DOCUBOT_REPO_PAT }}
result-encoding: string
script: |
// If being run from a PR, this becomes 'my-cool-branch'.
// If run on main, with the `workflow_dispatch` action for
// example, the value becomes 'main'.
const { BRANCH_NAME } = process.env
try {
const response = await github.repos.getBranch({
owner: 'github',
repo: 'docs-early-access',
BRANCH_NAME,
})
console.log(`Using docs-early-access branch called '${BRANCH_NAME}'.`)
return BRANCH_NAME
} catch (err) {
if (err.status === 404) {
console.log(`There is no docs-early-access branch called '${BRANCH_NAME}' so checking out 'main' instead.`)
return 'main'
}
throw err
}
- name: Check out docs-early-access too, if internal repo
if: ${{ github.repository == 'github/docs-internal' }}
uses: actions/checkout@v3
with:
repository: github/docs-early-access
token: ${{ secrets.DOCUBOT_REPO_PAT }}
path: docs-early-access
ref: ${{ steps.check-early-access.outputs.result }}
- name: Merge docs-early-access repo's folders
if: ${{ github.repository == 'github/docs-internal' }}
run: |
mv docs-early-access/assets assets/images/early-access
mv docs-early-access/content content/early-access
mv docs-early-access/data data/early-access
rm -r docs-early-access
# This is necessary when LFS files where cloned but does nothing
# if actions/checkout was run with `lfs:false`.
- name: Checkout LFS objects
run: git lfs checkout
- name: Gather files changed
uses: trilom/file-changes-action@a6ca26c14274c33b15e6499323aac178af06ad4b
id: get_diff_files
with:
# So that `steps.get_diff_files.outputs.files` becomes
# a string like `foo.js path/bar.md`
output: ' '
- name: Insight into changed files
run: |
# Must to do this because the list of files can be HUGE. Especially
# in a repo-sync when there are lots of translation files involved.
echo "${{ steps.get_diff_files.outputs.files }}" > get_diff_files.txt
- name: Setup node
uses: actions/setup-node@v3
with:
node-version: 16.14.x
cache: npm
- name: Install dependencies
run: npm ci
- name: Cache nextjs build
uses: actions/cache@v3
with:
path: .next/cache
key: ${{ runner.os }}-nextjs-${{ hashFiles('package*.json') }}
- name: Run build script
run: npm run build
- name: Run tests
env:
DIFF_FILE: get_diff_files.txt
CHANGELOG_CACHE_FILE_PATH: tests/fixtures/changelog-feed.json
run: npm test -- tests/${{ matrix.test-group }}/
Vue d’ensemble de l’exemple
Le tableau suivant explique comment chacune de ces fonctionnalités est utilisée lors de la création d’un workflow GitHub Actions.
Code | Explication |
---|---|
|
Nom du workflow tel qu’il apparaît sous l’onglet « Actions » du dépôt GitHub. |
|
Le mot clé |
|
Ajoutez l’événement |
|
Ajoutez l’événement |
|
Ajoutez l’événement |
|
Modifie les autorisations par défaut octroyées à |
|
Crée un groupe d’accès concurrentiel pour des événements spécifiques, et utilise l’opérateur |
|
Annule tout travail ou workflow en cours d’exécution dans le même groupe d’accès concurrentiel. |
|
Regroupe tous les travaux qui s’exécutent dans le fichier de workflow. |
|
Définit un travail ayant l’ID |
|
Configure le travail pour qu’il s’exécute sur un exécuteur hébergé par GitHub ou sur un exécuteur autohébergé, selon le dépôt qui exécute le workflow. Dans cet exemple, le travail s’exécute sur un exécuteur autohébergé si le dépôt se nomme |
|
Définit le nombre maximal de minutes d’exécution du travail avant qu’il ne soit automatiquement annulé. Pour plus d’informations, consultez |
|
Cette section définit la matrice de build de vos travaux. |
|
L’affectation de la valeur |
|
Crée une matrice nommée |
|
Regroupe toutes les étapes qui vont s’exécuter dans le cadre du travail |
|
Le mot clé |
|
Si le dépôt actuel est le dépôt |
|
Si le dépôt actuel est le dépôt |
|
Si le dépôt actuel est le dépôt |
|
Cette étape exécute une commande pour extraire les objets LFS du dépôt. |
|
Cette étape utilise l’action |
|
Cette étape exécute une commande d’interpréteur de commandes qui utilise une sortie de l’étape précédente pour créer un fichier contenant la liste des fichiers changés dans la demande de tirage. |
|
Cette étape utilise l’action |
|
Cette étape exécute la commande d’interpréteur de commandes |
|
Cette étape utilise l’action |
|
Cette étape exécute le script de build. |
|
Cette étape exécute les tests à l’aide de |
Étapes suivantes
- Pour découvrir les concepts de GitHub Actions, consultez « Comprendre GitHub Actions ».
- Pour un guide plus détaillé sur la création d’un workflow de base, consultez Démarrage rapide pour GitHub Actions.
- Si vous êtes à l’aise avec les bases de GitHub Actions, vous pouvez vous renseigner sur les workflows et leurs caractéristiques dans À propos des workflows.