cronwake-testbed

Repo de test pour Cronwake. Contient des workflows GitHub Actions planifies qui couvrent les cas normaux, limites, et tordus. Sert a verifier que Cronwake decouvre, parse, et surveille correctement, et a nourrir la "data story" (GitHub qui ne lance pas toujours les crons planifies).

Repo volontairement public : les minutes GitHub Actions sont illimitees sur un repo public, donc les crons frequents (toutes les 5 min) ne coutent rien.

Ce que Cronwake doit afficher apres decouverte

Fichier	cron	Ce que ca teste	Attendu dans Cronwake
nominal-5min.yml	*/5 * * * *	cadence rapide, suivi des runs	monitor, statut "ok", last run recent
nominal-hourly.yml	0 * * * *	cadence horaire	monitor "ok"
nominal-daily.yml	30 6 * * *	cadence quotidienne	monitor "ok"
nominal-failing.yml	*/15 * * * *	le run a lieu mais ECHOUE (exit 1)	monitor "ok" cote cadence ; derniere conclusion = failure + lien logs remontes
edge-multi-cron.yml	*/10 + 0 0 * * *	plusieurs crons	monitor avec les 2 crons affiches
edge-weekly.yml	0 9 * * 1	jour de semaine	monitor "ok"
edge-monthly.yml	0 0 1 * *	longue periode (mensuel)	monitor "ok"
edge-schedule-plus-push.yml	*/30 (+ push)	declencheurs multiples	monitor present ; les runs "push" ne comptent pas
edge-dispatchable.yml	*/15 (+ workflow_dispatch)	planifie ET relancable a la main	monitor "dispatchable" = true (bouton "Run on GitHub")
edge-slow.yml	*/15 * * * *	job LENT (~3 min)	monitor "ok" ; alerte "slow" si opt-in ; duree dans l'historique
edge-zero-day.yml	0 3 1 1 *	cron ultra-rare, ne tourne pas	monitor DECOUVERT sans lastRun, PAS de fausse alerte (couverture jour zero)
edge-cron-range.yml	0 9-17 * * 1-5	plages (heures + jours)	monitor "ok" ; prochaine occurrence en heure ouvree
edge-cron-list.yml	0 0,6,12,18 * * *	liste d'heures	monitor "ok" ; prochaine occurrence = la plus proche des 4
edge-timezone.yml	30 5 * * 1-5 (TZ New York)	champ timezone: (mars 2026)	monitor decouvert, cron parse, pas de crash sur le champ TZ
nasty-every-minute.yml	* * * * *	trop frequent (GitHub plafonne)	monitor "ok", PAS de fausse alerte (grace)
disable-me.yml	*/5 * * * *	scenario desactivation	monitor "ok" puis "disabled" apres desactivation
nasty-no-schedule.yml	(aucun, push)	pas de cron	AUCUN monitor (ne doit pas apparaitre)
nasty-invalid-cron.yml	61 2 * * *	cron invalide (minute 61)	AUCUN monitor (filtre, pas de crash)

Donc : 16 monitors attendus, et 2 workflows volontairement ignores (no-schedule et invalid-cron).

Scenarios manuels a jouer

1. Decouverte (immediat)

Installer/donner acces a Cronwake sur ce repo, attendre ~1-2 min, ouvrir le dashboard : les 16 monitors doivent apparaitre avec le bon cron. Les 2 "ignores" ne doivent pas etre la.

2. Suivi "ok" (apres ~5-15 min)

GitHub met quelques minutes a activer les nouveaux crons. Une fois que nominal-5min a tourne une fois, son "last run" doit se rafraichir et le statut rester "ok".

3. Contexte riche sur un echec (nominal-failing)

nominal-failing tourne puis echoue. Sur sa page de monitor (et dans l'alerte si un run vient a manquer), la derniere conclusion doit etre failure avec un lien cliquable vers les logs du run sur GitHub. Desactive-le une fois verifie pour couper les e-mails d'echec envoyes par GitHub.

4. Job lent + alerte slow (edge-slow)

Active l'alerte "slow-job" sur le monitor edge-slow (opt-in, dans ses reglages) avec un seuil sous ~3 min. Apres un run, une alerte "slow" doit partir, et la duree (~200 s) apparaitre dans l'historique.

5. Desactivation silencieuse (test cle)

Dans l'onglet Actions de ce repo, ouvre le workflow disable-me, clique "..." > Disable workflow. A la prochaine ronde de Cronwake, son statut doit passer a "disabled" et une alerte partir. Reactive-le ensuite : le monitor doit revenir "ok" (alerte de recovery).

6. Couverture jour zero (edge-zero-day)

edge-zero-day a un cron annuel : il ne tournera pas pendant le test. Il doit quand meme etre DECOUVERT et visible (sans lastRun) et ne PAS declencher de fausse alerte.

7. Forcer un "missed"/"late" (sans attendre une vraie panne)

Une vraie panne GitHub est rare et imprevisible. Pour tester le chemin d'alerte tout de suite, on triche proprement cote base : on recule le "last_run_at" d'un monitor frequent pour simuler qu'il n'a plus tourne depuis longtemps. (Voir la commande SQL fournie le moment venu.) A la ronde suivante, le monitor doit passer "late" puis "missed", et alerter, puis "recovered" au run suivant.

8. Parsing des expressions (edge-cron-range, edge-cron-list, edge-timezone)

Verifie sur ces monitors que la "prochaine occurrence" affichee est coherente avec l'expression (heure ouvree pour range, la plus proche des 4 heures pour list). Pour timezone, verifie surtout que Cronwake ne casse pas sur le champ timezone: (le calcul en fuseau est une limite connue a documenter).