Du raspberry au PC ... en passant par l'action GitHub

Je vous parlais il y a quelques semaines déjà de mon lifestream, et du fait que je dépassai les limites de traitement de mon Raspberry. Et même si je sais parfaitement que le code, dans son état de l'époque, tournait raisonnablement bien sur mon PC, l'idée de lancer une tâche planifiée m'enthousiasmait ... moyennement.

Et puis, les "projets perso" sont l'occasion idéale de tester des technologies plus ou moins pratiques. En l’occurrence, ça n'est pas vraiment un test, puisque c'est une technologie que j'ai déjà utilisée pour rrss2imap : GitHub Actions !

J'ai donc ajouté dans mon projet GitHub une action qui lance mon build maven et ... c'est là que les choses ont dérapé.

En effet, à cause de wordpress.com, j'ai dû il y a un long moment le très chouette HtmlUnit par le presque aussi chouette, mais beaucoup plus lourd, Selenium. Evidement, les instances Docker qui font tourner les workflows GitHub ne contiennent pas d'installation de Chrome, et encore moins d'installation de Chrome disposant de Selenium. Pour ça, il faut passer par la possibilité qu'offe Selenium d'utiliser un runner distant ... Et de l'action GitHub qui va bien (en l'occurence start-selenoid-server). Parce qu'évidement, comme il est plus simple de faire compliqué, le projet selenium a une longue, belle, et intéressante histoire. Et le passage au monde des conteneurs a là aussi fait des ravages. Donc pour faire tourner des runners Selenium dans le monde Docker, on utilise ... Selenoid ! L'avantage de Selenoid, c'est qu'il tourne dans tous les environnements Docker. L'inconvénient de Selenoid, c'est que l'installation dévie subtilement de la méthode traditionnelle des conteneurs, en passant par un curieux Configuration Manager. C'est sans doute pour démarrer le conteneur d'orchestration avec un accès à la socket Docker ... Parce que je ne vous ai pas expliqué, mais dans selenoid, il y a en fait plusieurs conteneurs : un orchestrateur qui reçoit les requêtes des clients Selenium et démarre les conteneurs hébergeant les conteneurs, et les conteneurs hébergeant les différents navigateurs. En bonus, l'utilisateur qui veut accéder aux navigateurs grâce à un client VNC web peut utiliser selenoid-ui, qui permet aussi de télécharger des vidéos des sessions de navigation.

Tout ça est fort bien. Mais, comme il n'y a pas de médaille qui n'ait son revers, certaines choses deviennent plus difficiles. Dans mon cas, il s'agit du téléchargement de fichiers. Parce que si j'utilise Selenium et un navigateur Chrome, c'est pour pouvoir télécharger les exports des données de différents sites. Et si télécharger un backup depuis un Chrome local est facile, télécharger le même backup depuis un Chrome tournant dans un conteneur distant se révèle une autre salade.

D'abord, il faut pouvoir télécharger un fichier depuis le conteneur, ce que permet selenoid grâce à son API http.

Ca marche bien dans des cas simples. Par exemple, pour goodreads, l'export est disponible via un lien HTTP. Donc quand je récupère la cible du lien avec Selenium, je peux obtenir le nom du fichier tel qu'il sera téléchargé par le navigateur, et utiliser ensuite l'api http pour télécharger le fichier localement.

En revanche, pour Wordpress, c'est plus délicat. Quand je clique sur le bouton "générer un export", wordpress génère un fichier dont le nom est timestampé. Et je dois donc localiser le nom du fichier avant de le télécharger.

Et tout ça marche très bien ... en local.

Parce que dès que j'exécute le bout de code dans GitHub Actions, je reçois cette erreur

Error: Failed to execute goal org.ndx.lifestream:goodreads:0.0.1-SNAPSHOT:goodreads (download goodreads) on project my-lifestream: there was a failure during pages construction: org.ndx.lifestream.plugin.exceptions.UnableToDownloadContentException: unable to download CSV from Goodreads: provided url http://localhost:4444/wd/hub can't be parsed: Could not copy "http://localhost:4444/download/e3b9d591ff9f4e3d26669cecfb1104c8/goodreads_library_export.csv" because it does not exist. -> [Help 1]

Voir par exemple cette exécution.

Et là, j'ai testé tout ça plusieurs fois, et je n'ai trouvé aucune solution pour corriger ça. ce qui fait que cette génération de lifestream marche bien (mais un poil lentement - 2 heures, à peu près) sur ma machine, mais plante en 3 minutes chrono chez GitHub.

Cela dit, j'ai quand même appris quelques détails amusants sur le pilotage de navigateurs. Et j'ai pu remplacer le Chromium avec Selenium qui tourne localement sur ma machine par un Chromium qui tourne dans Docker, ce qui est plus classe, et plus portable, je trouve. Par contre, je me retrouve quand même avec ce long build maven qui tourne sur ma machine, ce qui ne m'enchante pas du tout. Mais je vais trouver une autre solution.