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
Remarque : Lorsque l’accès concurrentiel est spécifié au niveau du travail, l’ordre n’est pas garanti pour les travaux ou exécutions en file d’attente avec moins de 5 minutes d’écart.
Vous pouvez utiliser jobs.<job_id>.concurrency
pour vous assurer qu’un seul travail ou workflow utilisant le même groupe d’accès concurrentiel s’exécute à la fois. Un groupe d’accès concurrentiel peut être n’importe quelle chaîne ou expression. Contextes d’expression autorisés : github
, inputs
, vars
, needs
, strategy
et matrix
. Pour plus d’informations sur les expressions, consultez « Expressions ».
Vous pouvez également spécifier concurrency
au niveau du workflow. Pour plus d’informations, consultez concurrency
.
Quand un travail ou un workflow simultané est mis en file d’attente, si un autre travail ou workflow utilisant le même groupe d’accès concurrentiel dans le dépôt est en cours d’exécution, le travail ou le workflow en file d’attente a la valeur pending
. Tout travail ou workflow en attente dans le groupe d’accès concurrentiel est annulé. Pour annuler également un travail ou un workflow en cours d’exécution dans le même groupe d’accès concurrentiel, spécifiez cancel-in-progress: true
.
Remarque : le nom de groupe d’accès concurrentiel ne respecte pas la casse. Par exemple, prod
et Prod
sera traité comme le même groupe d’accès concurrentiel.
Exemples : Utilisation de la concurrence et du comportement par défaut
concurrency: staging_environment
concurrency: ci-${{ github.ref }}
Exemple : Utilisation de la concurrence pour annuler un travail ou une exécution en cours
concurrency:
group: ${{ github.ref }}
cancel-in-progress: true
Exemple : Utilisation d’une valeur de secours
Si vous créez le nom de groupe avec une propriété définie uniquement pour des événements spécifiques, vous pouvez utiliser une valeur de secours. Par exemple, github.head_ref
est défini uniquement pour les événements pull_request
. Si votre workflow répond à d’autres événements en plus des événements pull_request
, vous devez fournir une valeur de secours pour éviter une erreur de syntaxe. Le groupe d’accès concurrentiel suivant annule les travaux ou les exécutions en cours pour les événements pull_request
uniquement. Si github.head_ref
n’est pas défini, le groupe d’accès concurrent utilise l’ID d’exécution, qui offre la garantie d’être à la fois unique et défini pour l’exécution.
concurrency:
group: ${{ github.head_ref || github.run_id }}
cancel-in-progress: true
Exemple : Annuler uniquement les travaux ou les exécutions en cours pour le workflow actuel
Si vous avez plusieurs workflows dans le même dépôt, les noms de groupes d’accès concurrentiel doivent être uniques au sein de tous les workflows pour éviter l’annulation de travaux ou d’exécutions en cours à partir d’autres workflows. Sinon, tout travail en cours ou en attente est annulé, quel que soit le workflow.
Pour annuler uniquement les exécutions en cours du même workflow, vous pouvez utiliser la propriété github.workflow
afin de créer le groupe d’accès concurrentiel :
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true