docs(renovate): record why the portal does not automerge dependency prs #206
Inga granskare
Etiketter
Inga etiketter
area/backups
area/ci
area/control-panel
area/identity
area/infra
area/observability
area/payments
area/security
area/storage
area/web
blocked
needs-info
needs-triage
ready-for-implementation
type
bug
type
chore
type
docs
type
epic
type
feature
type
task
wontfix
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Inget förfallodatum satt.
Beroenden
Inga beroenden satta
Referens
bitborg/bitborg-web!206
Läser in…
Hänvisa till i nytt ärende
Ingen beskrivning angiven.
Ta bort grenen "chore/renovate-no-automerge-rationale"
Borttagning av en gren är permanent. Även om den borttagna grenen kan fortsätta existera en kort tid innan den faktiskt tas bort, kan det INTE ångras i de flesta fall. Vill du fortsätta?
Companion to bitborg-docs #81, which adds an opt-in
automerge-safeRenovate preset.This repo deliberately does not extend it, and this records why so it does not have to be re-derived later.
A merge to
mainhere is a production deploy:deploy.ymlfires on push tomain, builds the image, pushes it to the registry, and the services host pulls it viapodman auto-update(ADR 0019) with no operator present. CI is a genuinely strong gate — gitleaks over full history,pnpm audit, astro check, eslint, stylelint, prettier, markdownlint, lang-check,drizzle-kit check, build, and vitest with coverage — and a failed healthcheck rolls the container back. But neither proves a bumped dependency left the served portal behaving the same, only that it builds and passes.So every dependency PR here stays human-reviewed. The note also states the constraint on any future change of mind: scope automerge to devDependencies only, never to runtime
dependencies, since those ship into what visitors execute.Comment only — no behaviour change in this repo. The volume reduction (weekly batching, toolchain grouping) reaches this repo through the shared preset regardless.
df34d83ca6f79220585f