PrestaFlow : consulter l'historique cloud de son projet depuis l'app

Décor

L’article Piloter ses tests depuis l’application PrestaFlow s’est arrêté à « Sync now → le run apparaît côté plateforme ». On s’y arrête ici pour aller à l’étape suivante : consulter l’historique complet du projet depuis l’app, en agrégeant tout ce qui arrive sur prestaflow.io — quelle que soit la source.

Sur un projet actif, la plateforme reçoit des runs de plusieurs endroits :

Depuis la CI — chaque push déclenche l’Action GitHub qui pousse son résultat.
Depuis d’autres desktops — vos collègues qui utilisent l’app et cliquent Sync now sur leurs runs locaux.
Depuis l’API — n’importe quel script qui envoie un POST /api/projects/{id}/runs avec un token valide (c’est le même point d’entrée que le Sync now de l’app).

Tout cela vit au même endroit sur la plateforme. La vue Cloud runs de l’app est la fenêtre par laquelle on regarde cette timeline unifiée, sans quitter le contexte de son projet local.

Où c’est

Depuis la page Settings de votre projet local (par exemple psflowdemo, si vous suivez le fil rouge de la série), deux chemins mènent à la même vue :

L’onglet Cloud runs, entre Settings et Tokens, affiché dès que le projet est lié à un projet cloud.
Le bouton Cloud runs de la carte de liaison cloud, dans la même page, une fois le projet lié (voir l’article sur l’app pour l’étape de liaison).

Ce que la liste affiche

Une liste paginée, une ligne par run, avec les colonnes qui comptent en pratique :

Status — une pastille passed (vert), failed (rouge), running (bleu) ou pending (gris).
Branch et Commit (les 7 premiers caractères du SHA) — pour situer le run dans l’historique Git du projet.
Uploaded via — la source du run, telle que la plateforme l’a enregistrée : desktop pour un run envoyé par Sync now (ou par un script qui appelle le même point d’API), github_action pour un run poussé par l’Action GitHub. C’est cette colonne qui rend la vue vraiment utile : d’un coup d’œil, vous savez si le run vert que vous regardez vient de votre CI ou du desktop d’un collègue qui teste dans son coin.
When — la date d’upload en relatif (« il y a 3 minutes »).
Un lien Delete en bout de ligne, avec confirmation, pour supprimer un run de la plateforme.

La liste affiche 20 runs par page, avec des boutons Previous / Next quand il y en a plus.

En tête de liste, deux filtres qui se combinent, appliqués par le bouton Filter (et remis à zéro par Clear) :

Branch — un champ texte pour restreindre à main, preprod, la branche d’une PR…
Status — All, Passed, Failed, Running ou Pending : ne voir que les échecs, par exemple, pour un rapide check santé.

Empty state explicite quand le projet n’a encore reçu aucun run : « No cloud runs yet — set up your CI to push results. »

Refresh et auto-refresh

Deux commandes en haut à droite de la vue :

Refresh — recharge la liste avec les filtres actuels. Un clic manuel, immédiat.
Auto-refresh 60s — une case à cocher qui, une fois cochée, recharge la vue toutes les 60 secondes. Un compte à rebours affiche le temps restant avant le prochain rechargement. La préférence est enregistrée dans localStorage, donc elle survit à un redémarrage de l’app.

Cas d’usage typique de l’auto-refresh : vous avez ouvert une PR il y a deux minutes, la CI tourne, vous continuez à coder — vous laissez l’onglet Cloud runs en second écran, il passe au vert (ou au rouge) tout seul quand le run finit.

Vue détail d’un run

Un clic sur une ligne ouvre la page dédiée au run, qui contient tout ce dont vous avez besoin pour comprendre ce qui s’est passé :

En-tête — le numéro du run, sa pastille de statut et le nom du projet.
Tuiles de stats — les compteurs calculés par la plateforme à l’ingestion : suites, tests, passed, failed, skipped, durée en millisecondes…
Meta — branche, SHA complet du commit, ref, CI run (l’identifiant du job de CI, affiché en texte), source (Uploaded via) et date d’upload en relatif. Seuls les champs renseignés apparaissent.
Galerie de captures — les images envoyées avec le run, avec une lightbox Alpine.js qui les ouvre en grand au clic. Comme PrestaFlow ne prend de capture qu’à l’échec d’une assertion, c’est là qu’on voit ce qu’un it échoué avait à l’écran. Un run sans capture affiche « No screenshots on this run. »
Bouton Download results.json — présent quand le run contient ce fichier. Il le télécharge via une URL pré-signée que l’API calcule à chaque affichage, valable une heure. Utile pour analyser les runs en local, faire des scripts d’agrégation, ou attacher le fichier à un ticket de bug.
Bouton Open on prestaflow.io — bascule vers l’interface web de la plateforme si vous voulez sortir de l’app.

Trois usages pratiques

Monitor de PR en second écran. Vous ouvrez la vue avec le filtre Branch sur feat/nouveau-checkout et l’auto-refresh coché, dans une fenêtre latérale. Vous restez concentré sur votre éditeur, l’app vous dit passivement quand la CI a fini.

Debug d’un échec CI depuis son desktop. Un run rouge apparaît sur la branche main. Vous cliquez, vous ouvrez la galerie de captures, vous téléchargez results.json. Vous n’ouvrez GitHub que si vous avez besoin de relancer manuellement le job — pour tout le reste, l’app suffit.

Vue d’équipe distribuée. Trois développeurs contribuent à un module. Chacun a l’app installée, chacun voit dans la liste les runs des autres (source desktop) et ceux de la CI. Vous savez qui a testé quoi, sans avoir à demander sur Slack.

Sous le capot

Deux points d’attention utiles à connaître :

Pas de cache local en v1. Chaque affichage de la liste appelle PrestaFlowApiClient::runs() sur la plateforme (GET /api/projects/{id}/runs). Idem pour la vue détail avec run($id) (GET /api/runs/{id}). Pratique : les données sont toujours fraîches. Contrepartie : sans connexion, la vue n’affiche pas de runs, seulement un bandeau d’erreur, jamais un crash.
Erreurs API traitées comme des états UI. Une session prestaflow.io expirée (401), un run introuvable (404) ou une erreur réseau produisent un bandeau d’erreur dans la liste, ou un encadré « Could not load this cloud run » avec le code HTTP dans la vue détail, avec un lien Go back. Pas de page 500 : c’est pensé pour un usage desktop où on peut perdre le réseau à tout moment.