GitHub Action de surveillance de site
Ajoutez une étape après votre déploiement. Relvato lance vos moniteurs sur le site en ligne et fait échouer le job quand l'un d'eux trouve un problème : un paiement cassé, une page qui a changé d'aspect, une extension vulnérable, une régression SEO, une page légale manquante.
L'Action utilise l'API de Relvato, incluse dans toutes les offres, Free compris. Il lui faut un site dont la propriété est prouvée et une clé API en accès complet.
Opérationnelle en trois étapes
Aucune application à installer dans GitHub : l'Action appelle l'API de Relvato avec une clé que vous gardez comme secret de dépôt.
Prouvez que le site vous appartient
Ajoutez le site dans Relvato et prouvez-en la propriété avec l'extension WordPress, un enregistrement DNS ou une balise meta. L'API ne lance des moniteurs que sur les sites dont la propriété est prouvée.
Enregistrez une clé en accès complet comme secret
Dans Relvato, ouvrez « API access » et créez une clé en accès complet. Dans GitHub, ouvrez Settings → Secrets and variables → Actions et enregistrez-la comme secret de dépôt nommé RELVATO_API_KEY.
Ajoutez l'étape après votre déploiement
Ajoutez Relvato/relvato-action@v1 à votre workflow avec la clé et votre site. L'Action attend les exécutions et fait échouer le job quand un moniteur trouve un problème.
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.examplesite accepte le domaine du site (myshop.example) ou son identifiant de site Relvato. Une clé en lecture seule ne peut pas lancer d'exécutions.
Lancez-la une fois le déploiement en ligne
Relvato lance vos moniteurs sur l'adresse du site : l'étape doit donc venir après que le déploiement a atteint la production. L'Action ne peut pas examiner un déploiement de prévisualisation avant sa promotion.
Après le job de déploiement, dans le même workflow
Le job verify attend deploy grâce à needs. Ici, il ne lance que les moniteurs de parcours (paiement, connexions, formulaires) et ne fait échouer le job que pour un problème élevé ou critique.
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh
verify:
needs: deploy
runs-on: ubuntu-latest
steps:
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.example
group: flow # checkout, logins, forms
min-severity: highAprès un déploiement en production sur Vercel, Netlify ou un autre hébergeur qui signale ses déploiements à GitHub
Le workflow démarre sur deployment_status et s'exécute une fois le déploiement en production réussi : quand il est en ligne, pas avant la promotion. Le nom de l'environnement est celui que signale votre hébergeur (Vercel utilise Production).
on: deployment_status
jobs:
verify:
if: github.event.deployment_status.state == 'success' && github.event.deployment.environment == 'Production'
runs-on: ubuntu-latest
steps:
- uses: Relvato/relvato-action@v1
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.exampleCe que fait une exécution lancée par votre workflow
Elle regarde le site en ligne
Relvato lance les moniteurs sur l'adresse de votre site. Placez l'étape après l'arrivée du déploiement en production : un déploiement de prévisualisation ne peut pas être examiné avant sa promotion.
Elle compte comme « Run now »
Chaque exécution compte dans les exécutions mensuelles de votre offre, une par moniteur. Un problème trouvé est aussi signalé sur les canaux de « Alert settings », comme pour toute exécution lancée à la main.
Non exécuté, c'est un avertissement
Si un pare-feu ou une protection anti-bots a bloqué Relvato, si le site n'a pas répondu ou si l'extension WordPress n'est pas à jour, le moniteur est un avertissement, pas un échec : cela ne dit rien de votre déploiement.
Seulement ce qu'un déploiement peut toucher
Utilisez group pour lancer un seul groupe de moniteurs, comme flow ou security, et min-severity pour fixer la gravité minimale qui fait échouer le job.
Entrées
| Entrée | Par défaut | Rôle |
|---|---|---|
api-key | — | Une clé API Relvato en accès complet. Obligatoire. |
site | — | Le domaine du site (myshop.example) ou son identifiant de site Relvato. Obligatoire. |
group | tous les moniteurs | Un seul groupe de moniteurs : uptime, flow (paiement, connexions, formulaires), security, design, performance, seo, domain ou compliance. |
fail-on | issue | issue : échoue quand un moniteur trouve un problème. any : aussi quand un moniteur n'a pas pu s'exécuter (un pare-feu a bloqué Relvato, le site était hors ligne) ou que le temps est écoulé. never : rapport seulement. |
min-severity | low | La gravité minimale qui fait échouer le job : warning, low, medium, high ou critical. |
timeout-minutes | 20 | Combien de temps attendre. Les moniteurs d'un site s'exécutent un par un : un ensemble complet peut prendre plusieurs minutes. |
Sorties
| Sortie | Contenu |
|---|---|
result | passed, issues, not-run ou timeout |
issues | Combien de moniteurs ont trouvé un problème de gravité min-severity ou plus |
not-run | Combien de moniteurs n'ont pas pu s'exécuter |
runs | Chaque exécution en JSON : id, monitor, outcome, severity, url |
site-url | La page du site dans Relvato |
Rapporter sans échouer
Avec fail-on: never, le job n'échoue pas ; une étape suivante peut lire la sortie result.
- uses: Relvato/relvato-action@v1
id: relvato
with:
api-key: ${{ secrets.RELVATO_API_KEY }}
site: myshop.example
fail-on: never
- run: echo "Relvato says ${{ steps.relvato.outputs.result }}"Vous préférez ne pas écrire de workflow ?
Pour un site ajouté en « Any website / AI-built app », vous pouvez connecter le dépôt GitHub depuis lequel vous déployez avec l'application GitHub de Relvato, ou ajouter le webhook de déploiement sur GitLab, Netlify, Railway ou Ghost. Relvato relance alors les moniteurs du site à chaque push ou déploiement, et un problème vous parvient par vos alertes habituelles. L'Action sert quand vous voulez le résultat dans le workflow lui-même, et que le job échoue en conséquence.
La GitHub Action, en questions
Quelles offres peuvent utiliser la GitHub Action ?
Toutes, Free comprise : l'Action utilise l'API de Relvato, présente dans chaque offre. Chaque exécution compte dans les exécutions mensuelles de votre offre, une par moniteur : utilisez group pour ne lancer que les moniteurs qu'un déploiement peut toucher.
Peut-elle examiner une prévisualisation Vercel ou Netlify avant sa promotion ?
Non. Relvato lance vos moniteurs sur l'adresse du site : il voit ce qui est en ligne. Lancez l'étape après l'arrivée du déploiement en production, par exemple sur deployment_status une fois le déploiement en production réussi.
Que se passe-t-il quand un moniteur n'a pas pu s'exécuter ?
C'est un avertissement dans le job, pas un échec : un pare-feu ou une protection anti-bots a bloqué Relvato, le site n'a pas répondu ou l'extension WordPress n'est pas à jour, ce qui ne dit rien de votre déploiement. Indiquez fail-on: any pour que le job échoue aussi dans ce cas.
Un problème trouvé déclenche-t-il aussi une alerte ?
Oui. Une exécution lancée par un workflow compte comme « Run now » dans le tableau de bord : un problème trouvé est donc aussi signalé sur les canaux que vous avez définis dans « Alert settings » (e-mail, Slack, Teams, Discord, Telegram, PagerDuty, webhook).
Pourquoi faut-il une clé en accès complet ?
Une clé en lecture seule peut lire les résultats mais pas lancer d'exécutions. Créez une clé en accès complet dans « API access » sur Relvato et enregistrez-la comme secret de dépôt nommé RELVATO_API_KEY.
Combien de temps cela prend-il ?
Les moniteurs d'un site s'exécutent un par un : un ensemble complet peut prendre plusieurs minutes. L'Action attend jusqu'à timeout-minutes (20 par défaut). Si des exécutions sont encore en cours à ce moment-là, le résultat est timeout, qui ne fait échouer le job qu'avec fail-on: any.
J'ai connecté GitHub à Relvato. Ai-je aussi besoin de l'Action ?
Seulement si vous voulez le résultat dans le workflow. L'application GitHub relance vos moniteurs à chaque push et vous prévient par vos alertes. L'Action s'exécute quand votre workflow le décide, affiche chaque moniteur dans le résumé du job et peut faire échouer le job.
Puis-je faire la même chose sans l'Action ?
Oui, avec l'API REST : POST /api/v1/sites/{id}/scan (éventuellement avec {"group": "flow"}), puis interrogez GET /api/v1/runs?siteId={id} jusqu'à ce que chaque exécution soit finished, et lisez son outcome (ok, issue, not-run) et sa severity.
D'autres façons de travailler avec Relvato
Sachez que le déploiement a fonctionné avant que vos visiteurs ne s'en aperçoivent
Prouvez la propriété du site, créez une clé en accès complet et ajoutez une étape à votre workflow.