Comment ignorer la tâche Actions GitHub lors d'un événement push?

Vous pouvez essayer ce qui suit:

name: Maven Build
on: [push]

jobs:
  build:
    if: "!contains(github.event.commits[0].message, '[skip ci]')"
    runs-on: ubuntu-latest

    steps:
    - name: Check-out project
      uses: actions/checkout@v1
    - name: Set up JDK 11.0.3
      uses: actions/setup-java@v1
      with:
        java-version: 11.0.3
    - name: Build with Maven
      run: mvn -B package --file pom.xml

Git 2,27 (Q2 2020) illustre une autre approche: au lieu de toujours construire toutes les branches à GitHub par actions, les utilisateurs peuvent spécifier les branches à construire.

Voir commit e76eec3 (07 mai 2020) par Jeff King ( peff ) .
^{(Fusionné par Junio C Hamano - gitster - dans commit dd4a287 , 13 mai 2020)}

ci : autorise la configuration par branche pour les actions GitHub

^{Signé par: Jeff King}

En fonction des flux de travail des développeurs individuels, il peut être pratique ou ennuyeux que nos tâches GitHub Actions CI soient exécutées sur chaque branche.

Par exemple, si vous transportez de nombreuses branches de travail en cours à moitié terminées et que vous les rebasez fréquemment contre master, vous obtiendrez des tonnes de rapports d'échec qui ne sont pas intéressants (sans parler du processeur gaspillé).

Cette validation ajoute un nouveau travail qui vérifie une branche spéciale dans le référentiel pour CI config, puis exécute un script shell qu'il y trouve pour décider s'il faut ignorer le reste des tests .

La valeur par défaut continuera à exécuter des tests pour toutes les références si cette branche ou ce script est manquant.

Quelques alternatives ont été discutées:

Une option est de transporter des informations dans le commit lui-même pour savoir s'il doit être testé, soit dans l'arborescence elle-même (en changeant le fichier YAML du workflow) soit dans le message de commit (un indicateur "[skip ci]" ou similaire). Mais ceux-ci sont frustrants et sujets aux erreurs:

• vous devez les appliquer manuellement à chaque branche que vous souhaitez marquer
• il leur est facile de s'infiltrer dans d'autres flux de travail, comme l'envoi de correctifs par courrier électronique

Nous pourrions également essayer d'obtenir des informations à partir du nom de la branche. Mais cela conduit à des débats sur la question de savoir si la valeur par défaut doit être «off» ou «on», et le remplacement finit toujours par être un peu gênant.
Si nous par défaut sur "on", vous devez vous rappeler de nommer vos branches de manière appropriée pour ignorer CI.
Et si "off", vous finissez par devoir contorsionner vos noms de branche ou dupliquer vos poussées avec une refspec supplémentaire.

Par comparaison, la solution de ce commit vous permet de spécifier votre configuration une fois et de l'oublier, et toutes les données sont désactivées dans leur propre référence, où elles peuvent être modifiées par des fourches individuelles sans toucher l'arborescence principale.

Il y a eu quelques décisions de conception issues de la discussion sur la liste. Je vais résumer ici:

• nous pourrions utiliser l'API de GitHub pour récupérer la référence de configuration, plutôt qu'une véritable vérification (et ensuite simplement opérer dessus via du javascript).
  Nous devons toujours lancer une VM et contacter GitHub sur le réseau à partir de celle-ci de toute façon, donc cela ne sera pas beaucoup plus rapide.
  J'ai choisi d'utiliser shell pour garder les choses similaires à nos autres outils (et je pourrais vraiment implémenter allow-refs dans n'importe quelle langue que vous voulez). Cela facilite également le test local de votre script et sa modification dans le contexte d'une arborescence git.git normale.

• nous pourrions garder le refname bien connu hors de refs refs/heads/ pour éviter d'encombrer l'espace de noms de branche. Mais cela rend la manipulation difficile.
  En revanche, vous pouvez simplement " git checkout ci-config " pour apporter des modifications.

• nous pourrions supposer que le ref ci-config ne contient rien à part config (c'est-à-dire une branche sans rapport avec le reste de git.git ).
  Mais gérer les branches orphelines est gênant. Au lieu de cela, nous ferons de notre mieux pour extraire efficacement uniquement le répertoire ci/config utilisant un clone partiel peu profond, ce qui permet à votre branche ci-config d'être juste une branche normale, avec vos modifications de configuration en haut.

• nous pourrions fournir une interface plus simple, comme une liste statique de modèles de référence.
  Mais de toute façon, nous ne pouvons pas nous passer de faire tourner une machine virtuelle entière, alors nous pourrions aussi bien utiliser cette fonctionnalité pour rendre la configuration aussi flexible que possible.
  Si nous ajoutons plus de configuration, nous devrions être en mesure de réutiliser notre clone partiel pour définir plus de sorties.

Le script est donc ci/config/allow-refs.sample :

enabled=yes
if test -x config-repo/ci/config/allow-ref &&
         ! config-repo/ci/config/allow-ref '${{ github.ref }}'
then
  enabled=no
fi

Tout ce que le .github/workflows doit faire est

• Découvrez la branche spéciale et le script spécial qu'elle contient:

C'est:

git -c protocol.version=2 clone \
  --no-tags \
  --single-branch \
  -b ci-config \
  --depth 1 \
  --no-checkout \
  --filter=blob:none \
  https://github.com/${{ github.repository }} config-repo \
&& \
cd config-repo \
&& \
git checkout HEAD -- ci/config

• Vérifiez si la branche poussée est autorisée:

Lequel est:

#!/bin/sh
#
# Sample script for enabling/disabling GitHub Actions CI runs on
# particular refs. By default, CI is run for all branches pushed to
# GitHub. You can override this by dropping the ".sample" from the script,
# editing it, committing, and pushing the result to the "ci-config" branch of
# your repository:
#
#   git checkout -b ci-config
#   cp allow-refs.sample allow-refs
#   $EDITOR allow-refs
#   git commit -am "implement my ci preferences"
#   git push
#
# This script will then be run when any refs are pushed to that repository. It
# gets the fully qualified refname as the first argument, and should exit with
# success only for refs for which you want to run CI.

case "$1" in
# allow one-off tests by pushing to "for-ci" or "for-ci/mybranch"
refs/heads/for-ci*) true ;;
# always build your integration branch
refs/heads/my-integration-branch) true ;;
# don't build any other branches or tags
*) false ;;
esac

En outre, pour les fichiers et répertoires que vous souhaitez ignorer sur tous les push, vous pouvez configurer le flux de travail lui-même:

on:
  push:
    paths-ignore:
    - 'README.md'