Gå til innhold

Monitorering av automasjon

Beskrivelse

Denne sida forklarar korleis du kan monitorere at generering og publisering av artefakter fungerer som forventa.

GitHub Actions-loggar (primær monitorering)

I PoC-fasen er GitHub Actions-loggar den primære monitoreringsmekanismen.

Kvar finn eg loggane?

Hovudoversikt over alle workflows: 

https://github.com/brreg/linkml-datamodellering-no/actions

Spesifikke workflows:

Workflow URL Kva det gjer
generate.yml actions/workflows/generate.yml Validerer, genererer artefakter og publiserer til GitHub Pages
validate.yml actions/workflows/validate.yml Nattleg validering (02:00 UTC) som lagrar loggar til src/linkml/*/validation/ og opprettar PR ved endringar
release-please.yml actions/workflows/release-please.yml Opprettar release-PR automatisk
release.yml actions/workflows/release.yml Byggjer og pushar container-images ved release

Release-arbeidsflyt

Repoet brukar release-please for å automatisere release-PR-oppretting basert på Conventional Commits. Arbeidsflyten er todelt: automatisk PR-oppretting og manuell release-publisering.

Flytdiagram

flowchart TD
    Start([Push til main<br/>feat: eller fix:])
    RPCheck{Commit-type<br/>release-utløysande?}
    RPRun[release-please<br/>workflow køyrer]
    RPOpen{Open release-PR<br/>finst?}
    PRCreate[Opprettar ny<br/>release-PR]
    PRUpdate[Oppdaterer<br/>eksisterande PR]
    WaitMerge([Brukar mergar<br/>release-PR manuelt])
    CreateRelease([Brukar opprettar<br/>GitHub Release manuelt])
    Done([Ferdig])

    Start --> RPCheck
    RPCheck -->|Ja| RPRun
    RPCheck -->|Nei: style/docs/<br/>chore/test/ci/build/<br/>perf/refactor| Done
    RPRun --> RPOpen
    RPOpen -->|Nei| PRCreate
    RPOpen -->|Ja| PRUpdate
    PRCreate --> WaitMerge
    PRUpdate --> WaitMerge
    WaitMerge --> CreateRelease
    CreateRelease --> Done

    classDef automatic fill:#e1f5e1,stroke:#4caf50,stroke-width:2px
    classDef manual fill:#fff9c4,stroke:#fbc02d,stroke-width:2px
    classDef decision fill:#e3f2fd,stroke:#2196f3,stroke-width:2px

    class RPRun,PRCreate,PRUpdate automatic
    class WaitMerge,CreateRelease manual
    class RPCheck,RPOpen decision

Fargekodar:

  • 🟢 Grøn — automatisk prosess (køyrer utan brukarinngripen)
  • 🟡 Gul — manuell prosess (krev brukarhandling)
  • 🔵 Blå — avgjerdspunkt (logikk i workflow)

Manuell release-publisering

Etter at release-PR er merga, må brukar opprette GitHub Release manuelt. Dette er nødvendig fordi GITHUB_TOKEN i GitHub Actions manglar tilgang til å opprette releases i dette repoet.

Alternativ 1: Via GitHub UI

  1. Gå til Releases
  2. Klikk Draft a new release
  3. Klikk Choose a tag → skriv inn tag-namn (t.d. samt-bu-v1.0.4) → klikk Create new tag: samt-bu-v1.0.4 on publish
  4. Fyll inn:
  5. Release title: samt-bu 1.0.4
  6. Description: Kopier frå CHANGELOG.md eller skriv manuelt
  7. Klikk Publish release

Tips: Tag-namn og versjon finn du i release-PR-en (t.d. PR #25) eller i .release-please-manifest.json.

Alternativ 2: Via GitHub CLI

# Hent versjon frå manifest
VERSION=$(jq -r '."src/linkml/<domain>/<modell>"' .release-please-manifest.json)
COMPONENT="<modell>"

# Opprett release
gh release create "${COMPONENT}-v${VERSION}" \
  --title "${COMPONENT} ${VERSION}" \
  --notes "Release ${VERSION} for ${COMPONENT}"

Eksempel for samt-bu:

VERSION=$(jq -r '."src/linkml/samt/samt-bu"' .release-please-manifest.json)
gh release create "samt-bu-v${VERSION}" \
  --title "samt-bu ${VERSION}" \
  --notes "Release ${VERSION} for samt-bu"

Sjå CONTRIBUTING.md for fullstendig prosedyre.

Kva viser loggane?

generate.yml (viktigaste workflow):

  1. Validering:
  2. make lint — LinkML-schema lint
  3. make mcp-linkml-valider-modell — Policy-validering (bronze/silver/gold/felles-begrepskatalog/felles-datakatalog)

  4. make validate-instance — Instansvalidering av eksempelfiler

  5. Generering:

  6. make <domain> — Genererer SHACL, JSON Schema, OWL, Python, Protobuf, dokumentasjon, diagram

  7. make convert-data — Konverterer YAML til SKOS/Turtle og ModelDCAT-AP-NO

  8. Publisering:

  9. make docs-publish — Regenererer mkdocs-portal
  10. actions/deploy-pages@v1 — Publiserer til GitHub Pages

Eksempel på vellukka køyring: 

✓ lint (ngr-virksomhet)
✓ mcp-linkml-valider-modell POLICY=bronze
✓ generate ngr
✓ publish
✓ Deploy to GitHub Pages

Eksempel på feila køyring: 

✗ mcp-linkml-valider-modell POLICY=felles-begrepskatalog
  Error: Missing required field: dct:publisher

validate.yml (nattleg validering og logging):

  1. Validering per domene (parallell):
  2. Validerer skjema mot validation_policy frå build.yaml
  3. Validerer eksempelfiler mot skjema
  4. Validerer datafiler mot publiseringspolicyer

  5. Sjekkar at publiserte URI-ar ikkje er fjerna

  6. Logglagring:

  7. Lagrar JSON-loggar til src/linkml/<domain>/<modell>/validation/<version>/<policy>.json

  8. Filtrerer ut uendra loggar (ignorer validated_at-felt)

  9. PR-oppretting (kun ved endringar):

  10. Opprettar PR med tittel: chore(validation): oppdater valideringsloggar (N modellar)
  11. PR inneheld kun loggar med faktiske endringar (nye violations eller forbettringar)
  12. Labels: automated, validation

Eksempel på vellukka køyring: 

✓ validate / ap-no
✓ validate / ngr
✓ Filtrer ut uendra loggar
  - 12 identiske (fjerna)
  - 3 endra (behelde)
  - 1 nye (behelde)
✓ Lag PR med valideringsloggar (4 modellar)

Når vert validate.yml køyrt? - Nattleg: kl 02:00 UTC (skriv loggar + opprett PR) - Manuelt: workflow_dispatch (skriv loggar + opprett PR) - PR-validering: ved pull_request mot skjema eller validator-kode (berre validering, ingen logging)

Kor lenge vert loggar lagra?

GitHub lagrar workflow-loggar i 90 dagar. Etter det vert dei automatisk sletta.

Korleis filtere loggar?

Filter på branch: - Klikk på "Branch"-dropdown og vel main, feature/mi-branch, osv.

Filter på status: - "Success" (grøn): Alt gjekk bra - "Failure" (raud): Validering eller generering feila - "Cancelled" (grå): Køyringa vart avbroten manuelt

Filter på dato: - "Event" → "Push" / "Pull request" / "Schedule"

Søk på commit-melding: - Bruk søkefeltet øvst: feat(ngr-adresse): legg til postnummer

Eksempel: Sjekke siste publisering

  1. Gå til https://github.com/brreg/linkml-datamodellering-no/actions/workflows/generate.yml
  2. Sjekk at øvste køyringa er grøn (✓)
  3. Klikk på køyringa for å sjå detaljert logg
  4. Sjekk "Deploy to GitHub Pages"-steget — vellukka dersom grøn hake

Verifisere publisering til GitHub Pages

Etter at generate.yml har køyrt vellukka, verifiser at artefaktane faktisk er publiserte til GitHub Pages.

Hovudportal

URL: https://brreg.github.io/linkml-datamodellering-no/

Kva som skal vere der: - MkDocs-dokumentasjonsportal - Navigasjonsmeny med domener (AP-NO, NGR, FINT, osv.) - Genererte skjema-sider med dokumentasjon og diagram

Genererte artefakter

Eksempel — SHACL shapes for ngr-virksomhet: 

https://brreg.github.io/linkml-datamodellering-no/ngr/ngr-virksomhet/ngr-virksomhet-shapes.ttl

Eksempel — JSON Schema: 

https://brreg.github.io/linkml-datamodellering-no/ngr/ngr-virksomhet/ngr-virksomhet-schema.json

Eksempel — Begrepskatalog (SKOS/Turtle): 

https://brreg.github.io/linkml-datamodellering-no/begrepskatalog/brreg-begrepskatalog/brreg-begrepskatalog.ttl

Verifisere at fila er oppdatert

Manuell sjekk:

curl -I https://brreg.github.io/linkml-datamodellering-no/ngr/ngr-virksomhet/ngr-virksomhet-schema.json

Sjekk Last-Modified-headeren: 

Last-Modified: Sun, 29 Jun 2026 14:32:15 GMT

Alternativ — sjekk i nettlesar: 1. Opne URL-en i nettlesar 2. Høgreklikk → "Inspiser" → "Network"-fanen 3. Refresh (F5) 4. Sjekk Last-Modified eller Date-headeren

Verifisere at høstingsendepunkt er tilgjengelege eksternt

Test at TTL-filer er tilgjengelege for Felles Begrepskatalog/Datakatalog:

curl -H "Accept: text/turtle" https://brreg.github.io/linkml-datamodellering-no/begrepskatalog/brreg-begrepskatalog/brreg-begrepskatalog.ttl

Dersom du får tilbake Turtle-data (startar med @prefix), fungerer høstingsendepunktet.

Framtidige monitoreringsalternativ

Desse alternativa kan leggjast til etter behov, men er ikkje nødvendige i PoC-fasen.

1. GoatCounter (besøksstatistikk)

Kva: Privacy-venleg, GDPR-compliant, open source web analytics
Kostnad: Gratis for open source-prosjekt
Implementering: ~30 minutt

Fordeler: - ✅ Ingen cookies — treng ikkje samtykke-banner - ✅ GDPR-compliant — perfekt for offentleg sektor - ✅ Open source - ✅ Viser: besøk per side, referrers, land, nettlesar

Korleis implementere:

  1. Registrer på https://www.goatcounter.com/
  2. Lag ein "site" (t.d. brreg-linkml)
  3. Legg til script-tag i MkDocs:

Opprett mkdocs/docs/overrides/main.html: 

{% extends "base.html" %}

{% block analytics %}
  <script data-goatcounter="https://brreg-linkml.goatcounter.com/count"
          async src="//gc.zgo.at/count.js"></script>
{% endblock %}

Oppdater mkdocs/mkdocs.yml: 

theme:
  name: material
  custom_dir: docs/overrides

  1. Push til main og vent på at GitHub Pages oppdaterar seg

Dashboard: https://brreg-linkml.goatcounter.com/

2. UptimeRobot (uptime-monitorering)

Kva: Overvaker at GitHub Pages er oppe og tilgjengeleg
Kostnad: Gratis tier (50 monitors, 5-minutts intervall)

Fordeler: - ✅ E-postvarsel dersom sida går ned - ✅ Historikk over uptime (99.9%, osv.) - ✅ Gratis for grunnleggjande behov

Korleis implementere:

  1. Registrer på https://uptimerobot.com/
  2. Legg til ny monitor:
  3. Monitor Type: HTTP(s)
  4. Friendly Name: LinkML Datamodellering Portal
  5. URL: https://brreg.github.io/linkml-datamodellering-no/
  6. Monitoring Interval: 5 minutt
  7. Legg til e-postadresse for varsel

Bruk: Automatisk varsel dersom GitHub Pages er nede

3. RSS-feed for releases

Kva: GitHub genererer automatisk RSS-feed for releases

URL: 

https://github.com/brreg/linkml-datamodellering-no/releases.atom

Bruk: - Abonner i RSS-lesar (Feedly, Inoreader, osv.) - Få varsel når ny versjon vert publisert

Avgrensingar

Avgrensingane under er ei direkte følgje av at repoet praktiserer "Pull, ikkje push" (sjå Publiseringsoversikt for full forklaring av prinsippet): repoet har ingen API-tilgang eller credentials mot eksterne katalogar, og kan difor ikkje overvake kva som skjer etter at artefakter er publiserte til GitHub Pages.

Kva repoet IKKJE kan monitorere

  1. Om Felles Begrepskatalog/Datakatalog faktisk høstar data
  2. Høsting skjer eksternt (Digitaliseringsdirektoratet sitt ansvar)
  3. Repoet har ingen API-tilgang til data.norge.no

  4. Må sjekkas manuelt på https://data.norge.no/concepts eller https://data.norge.no/models

  5. Besøksstatistikk på data.norge.no

  6. Statistikk frå data.norge.no er ikkje tilgjengeleg for oss

  7. Krev tilgang til Digitaliseringsdirektoratet sine analyseverkty

  8. Feilloggar frå eksterne system

  9. Dersom Felles Begrepskatalog feiler under høsting, får vi ikkje varsel
  10. Må kontakte Digitaliseringsdirektoratet ved mistanke om problem

Kva du må gjere manuelt

Verifisere at data faktisk er synleg på data.norge.no:

  1. Begrepskatalogar:
  2. Gå til https://data.norge.no/concepts
  3. Søk på eit begrep frå din katalog (t.d. "foretaksnavn")

  4. Verifiser at det visast med rett utgjevar og definisjon

  5. Modellkatalogar:

  6. Gå til https://data.norge.no/models
  7. Søk på din modell (t.d. "Nasjonale grunndata - Virksomhet")
  8. Verifiser at den visast med rett metadata

Kontakt Digitaliseringsdirektoratet dersom: - Data er publisert til GitHub Pages (verifisert) - Men ikkje visast på data.norge.no etter 24-48 timar - E-post: dataopen@digdir.no

Sjå òg