mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 04:32:42 +00:00
Marc-André Bombeck
d4d91994e8
The compose file runs Postgres 18. An install from v1.45 or earlier keeps its Postgres 16 data in `pgdata`, which 18 cannot open, so a one-shot `db-upgrade` service moves it on the first start: it starts Postgres 16 on the old volume inside its own container, streams a dump into 18 in one transaction, compares every table's row count, gathers planner statistics and marks the old volume as moved. The app waits for it to succeed. The old volume is never changed apart from the marker, so the way back is the previous image and volume lines. A move cut short leaves a "moving" marker and runs again from scratch; an emptied new volume after a finished move is refused rather than refilled with the old state. scripts/compose-db-upgrade-check.sh plays all of it against real containers from the v1.45.0 compose file, and runs in CI on every change to the compose file. Pull requests run the integration suite and e2e on Postgres 18; the nightly integration run keeps 16 covered for installs that bring their own database.
87 lines
3.7 KiB
YAML
87 lines
3.7 KiB
YAML
version: 2
|
|
updates:
|
|
- package-ecosystem: "npm"
|
|
directory: "/"
|
|
schedule:
|
|
interval: "weekly"
|
|
open-pull-requests-limit: 5
|
|
groups:
|
|
security-patches:
|
|
applies-to: security-updates
|
|
update-types:
|
|
- "patch"
|
|
# One weekly pull request per dependency kind instead of a trickle of
|
|
# single bumps: patch and minor updates travel together and pass the
|
|
# same checks once. Majors stay single so each gets its own review.
|
|
#
|
|
# The Next.js line travels alone. Its bumps are the ones that move
|
|
# URL state after history traversal (see the note on 16.4 below), and a
|
|
# red Next bump inside the group would hold every harmless update in
|
|
# it red as well.
|
|
production-weekly:
|
|
dependency-type: "production"
|
|
update-types:
|
|
- "patch"
|
|
- "minor"
|
|
exclude-patterns:
|
|
- "next"
|
|
development-weekly:
|
|
dependency-type: "development"
|
|
update-types:
|
|
- "patch"
|
|
- "minor"
|
|
exclude-patterns:
|
|
- "eslint-config-next"
|
|
- "@next/bundle-analyzer"
|
|
# No ignore for the Next.js line any more. 16.4.0 lost URL state after
|
|
# history traversal: with a sheet opened through `?doc=`, Back left it
|
|
# open, and `[` / `]` sometimes did not move `?day=` (3 of 40 repeated
|
|
# runs of three end-to-end journeys, 0 of 80 on 16.3.8). 16.4.2 does the
|
|
# same (the day keys lost a step in 2 of 20 runs locally, the `?doc=`
|
|
# journey failed once in CI). Both were ours to fix: the sheet followed
|
|
# `useSearchParams`, which 16.4 updates after the write it copies, and a
|
|
# day step wrote the URL before Next had adopted the previous step, whose
|
|
# late adoption then put the older URL back. The sheet now follows the
|
|
# address bar and a step waits for the layer. Measured after both fixes:
|
|
# 200 of 200 repeated runs of the three journeys, and another 80 of 80
|
|
# each for the `?doc=` and day-key journeys.
|
|
- package-ecosystem: "github-actions"
|
|
directory: "/"
|
|
schedule:
|
|
interval: "weekly"
|
|
open-pull-requests-limit: 3
|
|
groups:
|
|
# init, analyze and upload-sarif are one release pinned in three places.
|
|
# Bumped separately, a run mixes two versions and analyze refuses the
|
|
# config init wrote ("Loaded a configuration file for version 4.37.7, but
|
|
# running version 4.37.9"), so none of the single-action pull requests can
|
|
# reach green on its own. They travel together.
|
|
codeql-action:
|
|
patterns:
|
|
- "github/codeql-action*"
|
|
- package-ecosystem: "docker"
|
|
directory: "/"
|
|
schedule:
|
|
interval: "weekly"
|
|
open-pull-requests-limit: 3
|
|
# The `docker` ecosystem above reads the Dockerfile only. The bundled
|
|
# database lives in `docker-compose.yml`, which GitHub treats as its own
|
|
# ecosystem, so without this block a new PostgreSQL minor release never
|
|
# reaches us and the pin ages silently.
|
|
- package-ecosystem: "docker-compose"
|
|
directory: "/"
|
|
schedule:
|
|
interval: "weekly"
|
|
open-pull-requests-limit: 3
|
|
ignore:
|
|
# A PostgreSQL major is a migration, not an update: the on-disk format
|
|
# changes, so the operator has to run pg_upgrade or dump and restore.
|
|
# The first run of this ecosystem proposed 16.15 -> 18.6, which would
|
|
# have handed self-hosters a database their data directory cannot be
|
|
# read by. Minor releases still arrive as PRs; a major is a deliberate
|
|
# project decision with a migration guide behind it. The ignore also
|
|
# keeps `db-upgrade` on 16: it exists to read Postgres 16 data, and a
|
|
# bump to 18 would leave it unable to start on the volume it moves.
|
|
- dependency-name: "postgres"
|
|
update-types: ["version-update:semver-major"]
|