Hvorfor lægge rapportering i CI?
Din CI-pipeline kører ved hvert push, uanset om nogen ser på det. Det gør den til det billigste sted at besvare spørgsmål der ellers kræver et menneske: Knækkede en ny udgivelse tilgængeligheden? Virker sitet overhovedet? Er de bugrapporter der kommer ind, gyldige? Et trin der fejler højt i CI koster sekunder. Det samme problem opdaget af en bruger koster tillid.
Alle tre actions nedenfor er almindelige YAML-trin uden kontooprettelse, uden API-nøgle og uden SaaS-abonnement. Hver er fastgjort til et flydende hovedversions-tag (@v1 / @v2), så du får fejlretninger automatisk uden pludselige breaking changes.
De tre actions
1. Valider bugrapporter: bugbottle-action@v1
Hvis du samler bugrapporter som JSON-filer (fra en feedback-widget, et formular-export eller et script), validerer denne action dem mod skemaet inde i dit workflow. En misdannet rapport fejler buildet i stedet for at rådne lydløst i en mappe. Den afslutter med fejlkode ved ugyldigt input, så den kan bruges som port før release.
2. Hold sitet i live: deskuptime@v1
En afhængighedsfri oppetidstjek der kører hvor end din CI kører. Peg den på en URL, og fejler trinnet hvis siden ikke svarer som forventet. Nyttig som post-deploy smoke test — især på statiske sites hvor "deployet lykkedes" og "sitet virker" er to forskellige spørgsmål.
3. Fang compliance-regressioner: compliance-site-check@v2
Kører en GDPR/EAA-orienteret compliancescanning mod en URL og viser fejl i jobloggen. Tilføj den efter hver udgivelse, så et fjernet privatlivspolitik-link eller en ødelagt samtyckemekanisme dukker op samme sted som dine tests.
Et komplet eksempel-workflow
Dette workflow kører efter udgivelse: det tjekker at sitet er oppe, scanner compliance og validerer indsamlede bugrapporter:
name: Post-deploy checks
on:
schedule:
- cron: '0 6 * * *' # dagligt kl. 06:00 UTC
workflow_dispatch:
jobs:
checks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Sitet er oppe
uses: mahope/deskuptime@v1
with:
url: https://example.com
- name: Compliance-scan
uses: mahope/compliance-site-check@v2
with:
url: https://example.com
- name: Valider bugrapporter
uses: mahope/bugbottle-action@v1
with:
path: ./reportsHvert trin består eller fejler synligt. Ingen dashboard at logge ind på, ingen mail-digest at ignorere — rødt er rødt, samme sted som teamet alligevel kigger.
Opsætning, trin for trin
- Opret workflowfilen. Gem den som
.github/workflows/post-deploy.ymli dit repository. - Peg URL'erne på dit eget site. Erstat
example.comoveralt. Duplikér jobbet med din staging-URL, hvis du også vil tjekke staging. - Til bugbottle: peg
pathpå mappen hvor rapportfilerne lander. Samler du ikke rapporter endnu, så fjern trinnet — de to andre står alene. - Commit og kør én gang manuelt via workflow_dispatch, så du har bekræftet alt er grønt før du stoler på skemaet.
Ingen af de tre actions kræver secrets, da ingen kalder eksterne tjenester. De læser dine inputs og arbejder lokalt på runneren.
Hvad dette erstatter
En typisk oppetidsovervågnings-SaaS starter omkring 70–100 kr./md. pr. site. Compliance-audits koster 15.000–70.000 kr. pr. engagement. Ingen af delene fanger regressioner mellem tjek. Et dagligt CI-job gør begge dele løbende — gratis — på infrastruktur (GitHub-hostede runners) du allerede betaler for: gratis for offentlige repositories og inkluderede minutter for private.
Prøv det på dit site først
Før du sætter CI op: se hvad compliance-scanneren finder på dit live-site — gratis, uden tilmelding, resultat på cirka ét minut.
Scan dit site gratis →CI-jobbet er gratis. At holde øje mellem builds er ikke.
Alt i denne guide er gratis, og det bliver gratis: de tre actions, workflow-filen og runner-minutterne. DeskUptime kommandolinjeværktøjet bag deskuptime@v1 er det samme værktøj du kan installere i dag — enkelttjek, SSL- og content-tjek og JSON-output, på så mange sider du vil. Ingen konto, ingen nøgle, ingen prøveversion. Er dit eneste spørgsmål "brød den seneste udgivelse sitet?", svarer action nummer to ovenfor det allerede.
Det kan ikke svare på den del artiklen giver dig i sin egen tekst. Tidsplanen er cron: '0 6 * * *' — dagligt kl. 06:00 UTC — så alt det her guide bygger er blindt i de øvrige 23 timer og 59 minutter af døgnet. Første afsnit siger det samme om tempoet: et problem opdaget af en bruger koster tillid, og en bruger finder det kun når de tilfældigvis kigger. Trinene læses desuden i en joblog som ingen åbner mellem builds — den "indbakke" hele denne guide argumenterer imod. DeskUptime Pro tilføjer præcis fem ting, og alle fem er navngivne begrænsninger i teksten ovenfor.
| Hvad du får | Gratis | DeskUptime Pro — 19 $ én gang |
|---|---|---|
| Denne guide og de tre GitHub Actions den installerer | denne side, i sin helhed | med i licensen |
| At tjekke et site fra terminalen eller et workflow | enkelttjek | med i licensen |
| Certifikatudløb og lydløse indholdsændringer | SSL- og content-tjek | de samme tjek |
| Maskinlæsbart step-output | JSON-output | med i licensen |
| Hvor du kigger, når noget er galt | jobloggen, når du tilfældigvis åbner den | desktop-app |
| Hvordan fejlen når dig | en rød række i Actions-loggen | webhook-alarmer — Slack, Teams, PagerDuty |
| Hvor tit et site tjekkes | én gang om dagen, kun på default-branchen | hvert 30. sekund |
| Hvor mange sider én licens dækker | tre URL'er | ubegrænsede sites |
| Hvad du vedlægger, når kunden spørger | — | kunderapport |
Engangspris, tre maskiner — licensen aktiveres på den maskine du kører CLI'en på, ikke pr. site. Er én joblog om dagen nok til et site med én person, er de tre actions ovenfor hele svaret, og du behøver aldrig betale for noget.