ADR-DS-003: CI/CD med GitHub Actions
Beslutning
All CI/CD kjøres med GitHub Actions, organisert i spesialiserte workflows gruppert etter prefiks: pr-, release-, deploy- og security-.
PR-workflows
Kjøres på pull requests mot main.
pr-build-and-preview.yml— Bygger alle pakker, kjører lint og tester, bygger Storybook, og deployer forhåndsvisning til Azure Static Web Apps. Inkluderer lisenssjekk og sikkerhetsaudit.pr-playwright.yml— Kjører Playwright-tester i Docker mot Storybook: screenshot-sammenligning og tilgjengelighetstesting.pr-eksempel-e2e.yml— Kjører funksjonell e2e mot eksempelappen i Docker. Trigges bare ved endringer i eksempelappen eller pakkene den bruker.pr-cleanup.yml— Sletter Azure-forhåndsvisningen når en PR lukkes.
Release-workflows
Versjonering og publisering er to workflows, ikke én. changesets/action velger alltid versjonering når det finnes uforbrukte changesets, så den kan ikke også brukes til å publisere på et senere tidspunkt.
release-versjons-pr.yml— Trigger: push til main. Kjørerchangeset versionviachangesets/actionog oppretter eller oppdaterer PR-en «chore: version packages». Publiserer ingenting.release-publiser.yml— Trigger: schedule, hver time i kjernetid på hverdager. Publiserer alt i den nyeste versjons-commiten som ikke allerede ligger på npm, pusher git-tags og oppretter en GitHub-release per pakke. Er alt publisert, gjør kjøringen ingenting. Pakkene publiseres med npm provenance — en kryptografisk kobling mellom npm-pakken og GitHub Actions-kjøringen som produserte den, slik at konsumenter kan verifisere at pakken faktisk ble bygget fra kildekoden i repoet. Autentiseringen mot npm skjer med Trusted Publishing (OIDC), uten tilgangstoken.
Publiseringen skjer fra versjons-commiten, ikke fra det main peker på når cron-jobben kjører. Ellers ville feature-PR-er som har landet i mellomtiden bli publisert under et versjonsnummer changeloggen deres ikke står i.
Deploy-workflow
deploy-docs.yml— Trigger: schedule, hver time i kjernetid på hverdager. Bygger docs, Storybook og eksempel-app fra den nyeste release-taggen og deployer til Azure Static Web Apps. En egen, billig sjekk-jobb avgjør først om det er noe å deploye: den krever at CDN-en faktisk svarer på URL-ene for de nyeste versjonene, og at den versjonen ikke alt er deployet. Kan kjøres manuelt med valgfri commit når en tekstfiks må ut før neste release.
Docs bygges fra release-taggen fordi package.json i det treet er den publiserte sannheten. Bygde vi fra main, ville installasjonseksemplene på nettstedet vist versjonsnumre som ennå ikke finnes på npm eller CDN.
Publisering til CDN
CDN-artefaktene bygges av et eget, internt repo (sparebank1utvikling/sb1-indeks) som poller Releases-API-et her, kloner de nye release-taggene, kjører CDN-bygget og laster opp til S3. Det skjer også på schedule, mellom npm-publiseringen og docs-deployen.
Kjeden er polling-basert og ikke event-basert fordi de to repoene ligger i ulike GitHub-organisasjoner — en webhook ville krevd at en credential med skrivetilgang til det interne repoet lå lagret i dette, som er offentlig.
Fordi hvert steg selv sjekker om det forrige er ute, er en forsinket eller droppet cron-kjøring ufarlig: steget gjør ingenting og prøver igjen neste time.
Security-workflows
security-codeql.yml— CodeQL-skanning av JavaScript på PR, push til main og ukentlig schedule. Funn av alvorligheterrorellerhighblokkerer merge via rulesettet for main.security-zizmor.yml— Skanner workflow-filer med Zizmor, et statisk analyseverktøy som finner sikkerhetsproblemer i GitHub Actions-konfigurasjoner (f.eks. script injection, overprivilegerte tokens). Kjøres ved endringer i.github/workflows/. Kjøringen feiler ved funn, men er ikke en påkrevd statussjekk — den ville blokkert alle PR-er som ikke rører workflow-filer.security-npm-deprecate.yml— Manuell workflow for å deprecate eller unpublish npm-pakker ved sikkerhetshendelser.
Drivere for beslutningen
- Tett integrasjon med GitHub — ingen separate tokens, bruker GITHUB_TOKEN
- God marketplace med ferdige actions for pnpm, Azure og GitHub Pages
- Innebygd secrets management via GitHub Secrets
- Alle på teamet kjenner GitHub Actions fra andre prosjekter
Bakgrunn
Prosjektet trenger automatisert bygging, testing, publisering og deployment. Kilden er GitHub, og vi ønsker sterk integrasjon mellom kode og CI/CD — ikke et separat verktøy som må autentiseres og vedlikeholdes ved siden av.
Problemstilling
Hvilken CI/CD-løsning gir best integrasjon med GitHub-basert kildekode, uten å innføre ekstra verktøy og autentiseringskompleksitet?
Konsekvenser
Hvem påvirkes?
Alle utviklere som pusher kode trigger workflows. Teamet vedlikeholder workflow-filer.
Ulemper
- Vendor lock-in til GitHub — vanskelig å flytte til annen platform uten å skrive om workflows
- YAML-konfigurasjon kan bli kompleks og er vanskelig å teste lokalt
Tiltak mot ulemper
- Workflows holdes enkle og modulære med klare ansvarsgrenser per prefiks
- Kompleks logikk flyttes til scripts som kan kjøres lokalt
Forkastede alternativer
CircleCI
En populær CI/CD-plattform med god ytelse og parallelliseringsevne.
Forkastet fordi: Ekstra integrasjon og kostnad. GitHub Actions gir tilsvarende funksjonalitet uten ekstra verktøy og med bedre GitHub-integrasjon.
GitLab CI
CI/CD integrert i GitLab, med sterk integrasjon mellom kode og pipelines.
Forkastet fordi: Kildekoden er på GitHub, og å flytte til GitLab bare for CI gir ekstra kompleksitet. Fordelene GitLab CI gir er de samme som GitHub Actions allerede tilbyr på GitHub-siden.
Jenkins
Et selvhostet, svært fleksibelt CI/CD-system med lang historikk.
Forkastet fordi: Krever egen infrastruktur å vedlikeholde. For et lite team er vedlikeholdsoverheaden ikke verdt fleksibiliteten.
Azure DevOps
Microsofts ALM-platform med Pipelines for CI/CD.
Forkastet fordi: Ekstra verktøy utenfor GitHub. SpareBank 1 bruker Azure for hosting, men kodeplatformen er GitHub — å splitte CI/CD til Azure DevOps gir unødvendig kompleksitet.
Deltakere