Le 14 août, j’ai relié plus proprement mon script server-deploy.sh à GitHub Actions. Le changement paraît petit dans l’historique : prise en charge du token GitHub, ajout de permissions et de variables d’environnement dans deploy.yml.
En pratique, il fallait faire traverser une information sensible entre deux morceaux qui ne vivent pas au même endroit : le workflow GitHub Actions et le script Bash exécuté sur mon VPS.
## Le workflow lançait le déploiement, pas l’authentification
Mon déploiement repose sur un script côté serveur. Il récupère le code avec git pull, puis poursuit le déploiement du site. Tant que je lançais ce script dans un environnement déjà capable d’accéder au dépôt, cette dépendance restait discrète.
L’intégration avec GitHub Actions l’a rendue visible.
Le workflow pouvait déclencher le script. Cela ne voulait pas dire que le processus chargé du git pull recevait automatiquement une identité utilisable par GitHub. Le job et le script Bash restaient deux contextes différents.
C’est le problème de départ : le déclenchement arrivait jusqu’au VPS, mais pas forcément l’authentification nécessaire à l’étape suivante.
## Utiliser le token du job plutôt qu’un accès implicite
GitHub crée un `GITHUB_TOKEN` pour chaque job. Ce token est limité au dépôt du workflow et expire à la fin du job. Il correspond bien à mon besoin : autoriser le déploiement courant à récupérer le code du dépôt courant.
J’ai donc modifié les deux côtés du passage.
Dans deploy.yml, j’ai déclaré les permissions nécessaires au workflow. GitHub permet de régler ces droits avec la clé `permissions`, au niveau du workflow ou d’un job précis. Pour récupérer du code, le besoin se situe du côté de la lecture du contenu du dépôt. Il n’y a aucune raison de donner plus de droits uniquement parce que c’est plus rapide à écrire.
Ensuite, j’ai transmis le token au script à travers une variable d’environnement. GitHub Actions permet de définir ces variables à plusieurs niveaux avec `env`. Dans mon cas, la variable sert surtout de contrat entre le YAML et Bash : le workflow fournit une valeur, le script sait où la lire.
Je n’ai pas ajouté une nouvelle couche de déploiement. J’ai rendu explicite une dépendance qui existait déjà.
## Ce qui coinçait se trouvait entre les deux fichiers
Le piège est que les deux changements sont nécessaires, mais qu’aucun ne suffit seul.
Déclarer une permission ne transmet pas magiquement le token à un autre processus. À l’inverse, créer une variable d’environnement ne donne pas au token des droits qu’il ne possède pas.
Il fallait donc aligner :
- les permissions accordées au job ;
- la valeur exposée par le workflow ;
- le nom attendu par
server-deploy.sh; - le moment où
git pullutilise cette valeur.
Ce n’était pas un problème compliqué dans chaque fichier. C’était un problème de frontière.
Le YAML décrit ce que GitHub Actions peut exécuter et ce qu’il reçoit. Le script Bash décrit ce que mon serveur fait réellement. Entre les deux, rien n’est automatique tant que je n’ai pas défini clairement les données qui traversent.
C’est aussi pour ça que je préfère garder cette intégration près du script existant. Le workflow ne réimplémente pas le déploiement. Il prépare son contexte, puis laisse le VPS faire le travail qu’il faisait déjà.
## Ce que ça donne maintenant
Le chemin d’authentification est maintenant explicite. Lorsqu’un job lance le déploiement, il fournit au script le token associé à cette exécution. Le git pull ne dépend plus, pour ce chemin, d’un accès GitHub implicite que je pourrais oublier en relisant le script dans quelques mois.
Le changement tient dans peu de lignes, mais il clarifie la responsabilité de chaque partie : GitHub Actions donne l’autorisation temporaire, server-deploy.sh l’utilise pour récupérer le code, puis le déploiement continue sur ma machine.
Le prochain point que je veux verrouiller est le cas où cette variable manque. Le script doit s’arrêter avant le git pull avec un message clair, plutôt que laisser Git produire une erreur d’authentification plus loin dans l’exécution. C’est la prochaine frontière à rendre visible.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.