Le 30 juillet, GitHub a ajouté une nouvelle syntaxe pour appeler une action ou un workflow réutilisable situé dans le même dépôt. Au lieu de passer par un chemin relatif comme ./.github/actions/deploy, on peut maintenant écrire uses: $/.github/actions/deploy.
La différence paraît petite. Elle règle pourtant un vrai problème : la référence $/ pointe vers le dépôt au commit exact qui exécute le workflow, sans imposer un checkout préalable. GitHub la présente désormais comme la syntaxe recommandée pour les actions locales.
Je viens justement d’ajouter GitHub Actions au déploiement de ce site. La nouveauté arrive donc au bon moment pour que je me pose la question : est-ce que mon pipeline doit l’utiliser ?
Pour l’instant, non.
## Ce que j’ai réellement mis en place
Le 14 août, j’ai relié mon déploiement à GitHub Actions. J’ai ajouté les permissions et les variables d’environnement dans deploy.yml, puis adapté server-deploy.sh pour qu’il puisse récupérer le dépôt avec le token fourni par GitHub Actions.
Le centre du déploiement reste ce script Bash. C’est lui qui porte les opérations liées au serveur. C’est aussi lui qui m’a déjà posé un problème précis : après avoir lancé git pull sur son propre fichier, Bash continuait d’exécuter l’ancienne version chargée en mémoire. J’ai dû rendre sa relance explicite.
Cette séparation me convient actuellement :
- le workflow déclenche et fournit son environnement ;
- le script décrit ce qui doit se passer sur mon VPS ;
- le dépôt contient les deux, mais ils n’ont pas besoin d’être emballés dans une action personnalisée.
La nouvelle syntaxe $/ ne sert pas à lancer n’importe quel fichier du dépôt. Elle référence une action possédant son fichier action.yml, ou un workflow réutilisable. La documentation GitHub confirme aussi que l’ancienne forme ./ demande que le dépôt soit déjà présent dans l’espace de travail, contrairement à $/.
Mon script de déploiement n’est pas une action GitHub. C’est volontaire.
## Transformer le script en action ne m’apporterait rien aujourd’hui
Je pourrais créer une action composite autour du script. Le workflow deviendrait alors plus lisible en surface :
- name: Déployer
uses: $/.github/actions/deployMais le travail ne disparaîtrait pas. Il serait déplacé dans un nouveau dossier, avec un fichier de métadonnées et une couche supplémentaire entre le workflow et le script.
Pour un comportement partagé entre plusieurs workflows, cette couche aurait un rôle. Pour mon déploiement actuel, elle ne ferait que renommer un appel que je comprends déjà.
C’est le même critère que j’applique ailleurs dans ma stack. Je ne cherche pas le moins de fichiers possible. Je cherche le moins de couches sans responsabilité claire. Une action locale doit représenter une unité réutilisable, pas seulement rendre trois lignes de YAML plus jolies.
La nouveauté de GitHub améliore surtout le moment où cette abstraction devient légitime. Si je crée un jour une action locale commune à plusieurs jobs, $/ évitera de dépendre d’un checkout et garantira que l’action vient du même commit que le workflow. La syntaxe fonctionne aussi avec les workflows réutilisables et demande un runner GitHub Actions en version 2.336.0 ou plus récente, d’après l’annonce officielle.
## Je garde le script visible
Je ne bascule donc rien. Mon workflow reste un déclencheur, et server-deploy.sh reste l’endroit où je lis le déroulement du déploiement.
Ce n’est pas un rejet de la nouvelle syntaxe. Elle corrige une faiblesse réelle des actions stockées dans leur propre dépôt. Je n’ai simplement pas encore cette faiblesse, parce que je n’ai pas encore cette abstraction.
La prochaine étape n’est pas de créer une action locale. C’est de continuer à observer ce qui se répète entre les déploiements de mes projets. Si une vraie unité commune apparaît, je pourrai l’extraire et utiliser $/. Jusque-là, le script reste un script.