Bugrapporter i din CI-pipeline: Komplet opsætning med 3 GitHub Actions

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: ./reports

Hvert 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.yml i dit repository.
Peg URL'erne på dit eget site. Erstat example.com overalt. Duplikér jobbet med din staging-URL, hvis du også vil tjekke staging.
Til bugbottle: peg path på 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 →