|
|
|
|
@@ -69,8 +69,8 @@ L'installation d'un [runner](https://docs.gitea.com/next/usage/actions/act-runne
|
|
|
|
|
|
|
|
|
|
Tout d'abord, il faut obtenir un token depuis Gitea.
|
|
|
|
|
Selon où vous le demandez, il est possible que le runner soit attribué à un unique projet, à une organisation, ou à toutes les organisations de l'instance.
|
|
|
|
|
Dans tous les cas, c'est dans les paramètres (du projet, de l'organisation, ou de l'instance de Gitea) qu'il faut aller, puis dans l'onglet "*Runners*".
|
|
|
|
|
On clique ensuite sur le bouton "*Create runner*", et on copie le token.
|
|
|
|
|
Dans tous les cas, c'est dans les paramètres (du projet, de l'organisation, ou de l'instance de Gitea) qu'il faut aller, puis dans l'onglet "_Runners_".
|
|
|
|
|
On clique ensuite sur le bouton "_Create runner_", et on copie le token.
|
|
|
|
|
|
|
|
|
|
Pour intégrer ce token à notre configuration de NixOS, nous avons plusieurs options :
|
|
|
|
|
|
|
|
|
|
@@ -130,7 +130,7 @@ echo -n "<token>" > ./gitea-actions-runner-token
|
|
|
|
|
|
|
|
|
|
Pour rappel, l'option `-n` permet d'éviter la ligne vide en fin de fichier (ce qui invaliderait le token), et là aussi, on remplacera `<token>` par le token copié précédemment.
|
|
|
|
|
|
|
|
|
|
***
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
Ensuite, on doit configurer des [labels](https://docs.gitea.com/next/usage/actions/act-runner#labels).
|
|
|
|
|
En - très - gros, il s'agit d'associer un nom à un container dans lequel seront exécutées les actions ou à la machine hôte.
|
|
|
|
|
@@ -138,8 +138,8 @@ En - très - gros, il s'agit d'associer un nom à un container dans lequel seron
|
|
|
|
|
Le package NixOS [ne propose pas encore de valeur par défaut](https://search.nixos.org/options?channel=23.05&show=services.gitea-actions-runner.instances.%3Cname%3E.labels&from=0&size=50&sort=alpha_asc&type=packages&query=gitea), et ce paramètre ne peut pas être vide.
|
|
|
|
|
Heureusement, la documentation de Gitea nous indique les valeurs utilisées par défaut par l'exécutable - mais sont obsolètes. Je me suis inspiré de la valeur d'exemple donnée par NixOS pour ma propre configuration.
|
|
|
|
|
|
|
|
|
|
Dans l'exemple que je vous montre, je pourrai lancer mes actions sur "*ubuntu-latest*", qui correspond à l'image docker de nodejs v18 sur une debian bullseye.
|
|
|
|
|
Et ce n'est qu'en écrivant ces lignes que je me rends compte que cet exemple est mauvais : le label *ubuntu-latest* ne correspond en rien à l'image utilisée...
|
|
|
|
|
Dans l'exemple que je vous montre, je pourrai lancer mes actions sur "_ubuntu-latest_", qui correspond à l'image docker de nodejs v18 sur une debian bullseye.
|
|
|
|
|
Et ce n'est qu'en écrivant ces lignes que je me rends compte que cet exemple est mauvais : le label _ubuntu-latest_ ne correspond en rien à l'image utilisée...
|
|
|
|
|
Je propose au lecteur, en guise d'exercice, de modifier cette ligne comme bon lui semblera 😊
|
|
|
|
|
|
|
|
|
|
Autre label que j'utilise, `native:host`, qui permettra de lancer les actions sur la cible `native`, la machine hôte.
|
|
|
|
|
@@ -181,7 +181,7 @@ Avec Gitea Actions, cela passe - par exemple - par le "code" yaml suivant :
|
|
|
|
|
uses: actions/checkout@v3
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Donc, pour récupérer **mes** sources sur **mon** serveur, il faut d'abord cloner le dépôt https://github.com/actions/checkout.
|
|
|
|
|
Donc, pour récupérer **mes** sources sur **mon** serveur, il faut d'abord cloner le dépôt <https://github.com/actions/checkout>.
|
|
|
|
|
Surprise : c'est tout en javascript.
|
|
|
|
|
Le redistribuable pèse pas loin d'1Mo de javascript, et [les sources](https://github.com/actions/checkout/tree/main/src) sont imbitables et en plus pas documentées.
|
|
|
|
|
Mais que fait donc tout ce javascript que le binaire `git` ne fait pas, à part quelques options de configuration ?
|
|
|
|
|
@@ -221,7 +221,7 @@ Pour "activer" l'usage de LFS, il faut rajouter une ligne :
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Je soupçonne là encore une intégration avec l'API de Github, parce qu'au niveau de git, il n'est nullement nécessaire de préciser qu'on veut utiliser LFS lors d'un `git clone`.
|
|
|
|
|
Mais sans cette option, le clonage de mon dépôt se fait sans LFS *sans que je sois au courant*.
|
|
|
|
|
Mais sans cette option, le clonage de mon dépôt se fait sans LFS _sans que je sois au courant_.
|
|
|
|
|
Ce n'est que bien plus tard, lors de la compilation des fichiers du site, que Hugo plante en essayant d'accéder à des fichiers qui n'existent pas.
|
|
|
|
|
|
|
|
|
|
Et c'est symptomatique d'absolument **tout** l'écosystème javascript (et Go, d'ailleurs) : **rien, absolument rien** n'est intuitif.
|
|
|
|
|
@@ -229,7 +229,7 @@ Tout est - mal - repensé, tout est superposition d'abstractions, et un utilisat
|
|
|
|
|
|
|
|
|
|
Ce fonctionnement contre-intuitif m'a forcé à remettre en question toute la chaîne de production de mon blog : est-ce que j'ai introduit un bug dans la gestion des images ? est-ce que j'utilise la bonne version d'Hugo ? me manque-t'il une dépendance ? pourquoi ça fonctionne sous Drone et pas sous Actions ? quelles différences entre les images dockers ? etc.
|
|
|
|
|
|
|
|
|
|
À aucun moment je n'ai eu droit à un message *explicite*.
|
|
|
|
|
À aucun moment je n'ai eu droit à un message _explicite_.
|
|
|
|
|
Et c'est encore une fois symptomatique de la philosophie moderne du développement : on doit cacher les erreurs et les problèmes à l'utilisateur pour ne pas créer de situations anxiogènes.
|
|
|
|
|
On n'arrête l'exécution d'un processus qu'en cas de situation critique.
|
|
|
|
|
On doit poursuivre l'exécution coûte que coûte.
|
|
|
|
|
@@ -238,7 +238,7 @@ Résultat, Hugo refuse de compiler certains templates parce que le "format d'une
|
|
|
|
|
Je modifie le template en question, essayant de corriger un bug qui n'existe pas.
|
|
|
|
|
Je relance la CI, je dois attendre d'arriver à la compilation des ressources après avoir téléchargé la moitié d'Internet pour la centième fois, et constater que le "bug" s'est "étendu" à d'autres fichiers.
|
|
|
|
|
|
|
|
|
|
Quand une application me dit "format d'image incorrect", je me dis qu'il manque une librairie particulière (du genre *libpng* ou *libjpeg*).
|
|
|
|
|
Quand une application me dit "format d'image incorrect", je me dis qu'il manque une librairie particulière (du genre _libpng_ ou _libjpeg_).
|
|
|
|
|
Je ne pense pas du tout à activer une option yaml pour que le clonage se fasse avec LFS...
|
|
|
|
|
|
|
|
|
|
C'est pas fini...
|
|
|
|
|
@@ -329,7 +329,7 @@ Tout à la fois content de trouver cette fonctionnalité assez attendue parmi le
|
|
|
|
|
Je lance, j'attends qu'on arrive à cette étape, et ça crashe, avec un message me disant que ma clé est invalide, dans une magistrale illustration de ma remarque d'avant (on poursuit d'exécution quoiqu'il arrive).
|
|
|
|
|
L'action a spammé mon serveur SSH après son infructueuse tentative d'utilisation de ma clé "invalide", continuant chaque étape comme si la clé avait été acceptée, pour faire... je ne sais pas trop quoi en fait, je voulais juste un `rsync` moi...
|
|
|
|
|
|
|
|
|
|
``` {linenos=false,class=not-prose}
|
|
|
|
|
```{linenos=false,class=not-prose}
|
|
|
|
|
[DIR] Creating /***/.ssh dir in workspace ***
|
|
|
|
|
✅ [DIR] dir created.
|
|
|
|
|
[FILE] writing /***/.ssh/known_hosts file ... 0
|
|
|
|
|
@@ -410,7 +410,7 @@ rsync error: unexplained error (code 255) at io.c(228) [sender=3.2.3]
|
|
|
|
|
Pourtant, cette même clé privée était utilisée par Drone depuis quelques années, sans le moindre problème.
|
|
|
|
|
|
|
|
|
|
En fait, c'est Gitea qu'il faut pointer du doigt ici.
|
|
|
|
|
Le formulaire pour soumettre un secret [supprime les espaces et les lignes vides](https://github.com/go-gitea/gitea/issues/24721), au début et *à la fin* de la chaîne soumise.
|
|
|
|
|
Le formulaire pour soumettre un secret [supprime les espaces et les lignes vides](https://github.com/go-gitea/gitea/issues/24721), au début et _à la fin_ de la chaîne soumise.
|
|
|
|
|
Or, une ligne vide est exigée en fin de chaîne pour qu'une clé privée soit considérée valide.
|
|
|
|
|
Et Gitea m'a prévenu : dans la zone de texte, où je colle ma clé privée, il est clairement indiqué que les espaces vides au début et en fin de chaîne seront supprimés, ce que je n'ai vu qu'après une journée de recherche de tout ce qui peut bien merder avec ma clé privée.
|
|
|
|
|
Et comme c'est un secret, je ne peux même pas essayer de l'afficher pour la débugguer, et vu qu'elle aurait de toute façon été formatée pour l'affichage dans l'onglet de la CI, je n'aurai probablement pas vu que la ligne vide finale était absente.
|
|
|
|
|
@@ -441,5 +441,5 @@ Mais moi qui n'y ais jamais mis les pieds, c'est, je le répète, absurdement co
|
|
|
|
|
|
|
|
|
|
En ce qui me concerne, j'arrête Gitea Actions, et je vais creuser du côté de [Woodpecker](https://woodpecker-ci.org/), fork de Drone qui dispose de paquets pour NixOS.
|
|
|
|
|
|
|
|
|
|
Le pire c'est que pour une fois, je ne suis pas fier de mon *rant* : j'avais vraiment envie que ça fonctionne, que ça me plaise, que ça me corresponde, que ça m'enthousiasme.
|
|
|
|
|
Le pire c'est que pour une fois, je ne suis pas fier de mon _rant_ : j'avais vraiment envie que ça fonctionne, que ça me plaise, que ça me corresponde, que ça m'enthousiasme.
|
|
|
|
|
Mais j'en suis très loin...
|
|
|
|
|
|
