marcel/familienarchiv
1
0
Fork 0
Code Issues 118 Pull Requests 2 Actions 4 Packages Projects Releases Wiki Activity

devops: bootstrap Renovate config for production deps (MinIO, mc, Postgres, Node, Caddy, mailpit) #500

New Issue
Open
opened 2026-05-11 13:19:22 +02:00 by marcel · 0 comments
marcel commented 2026-05-11 13:19:22 +02:00
Owner
Copy Link

Background

The repository's renovate.json only configures TipTap grouping. The production stack pins five third-party images via docker-compose.prod.yml:

  • postgres:16-alpine
  • minio/minio:RELEASE.2025-02-28T09-55-16Z
  • minio/mc:RELEASE.2025-08-13T08-35-41Z
  • axllent/mailpit:v1.29.7
  • node:20.19.0-alpine3.21 (via frontend/Dockerfile)
  • caddy:2 (Caddy is installed on the host, not via compose — but the same patch-lag risk applies)

Without an active Renovate config tracking these, the pins rot. Operator must remember to bump manually, which means in practice CVE bumps lag months.

This was flagged on PR #499 by Tobi (DevOps review, comment #8352) and Elicit (Requirements review, comment #8356, OQ-1).

Scope

Update renovate.json to:

  1. Extend config:base (or config:recommended) for the standard Docker / GitHub Actions / npm / Maven update rules.
  2. Add a dockerfile and docker-compose manager so the pinned image tags above are auto-tracked.
  3. Group updates by ecosystem (one PR per: docker images, npm devDeps, Maven deps) to keep the review surface manageable.
  4. Set a sensible auto-merge policy for minor/patch updates on dev-only deps; require manual review for production images and any major bumps.
  5. Confirm with the Gitea operator that the Renovate bot has access to the repository — if not, file the access-grant step here.

Acceptance criteria

  • renovate.json covers the five production image pins
  • First Renovate dependency-dashboard PR appears within 24h of merge
  • docker-compose.prod.yml comments about Renovate keeping pins current are accurate again (currently stripped in PR #499)

References

  • PR #499 — DevOps review (Tobi, #8352)
  • PR #499 — Requirements review (Elicit, #8356, OQ-1)
  • PR #499 — comment-strip commit reverting the aspirational language
## Background The repository's `renovate.json` only configures TipTap grouping. The production stack pins five third-party images via `docker-compose.prod.yml`: - `postgres:16-alpine` - `minio/minio:RELEASE.2025-02-28T09-55-16Z` - `minio/mc:RELEASE.2025-08-13T08-35-41Z` - `axllent/mailpit:v1.29.7` - `node:20.19.0-alpine3.21` (via `frontend/Dockerfile`) - `caddy:2` (Caddy is installed on the host, not via compose — but the same patch-lag risk applies) Without an active Renovate config tracking these, the pins rot. Operator must remember to bump manually, which means in practice CVE bumps lag months. This was flagged on PR #499 by Tobi (DevOps review, comment [#8352](https://git.raddatz.cloud/marcel/familienarchiv/pulls/499#issuecomment-8352)) and Elicit (Requirements review, comment [#8356](https://git.raddatz.cloud/marcel/familienarchiv/pulls/499#issuecomment-8356), OQ-1). ## Scope Update `renovate.json` to: 1. Extend `config:base` (or `config:recommended`) for the standard Docker / GitHub Actions / npm / Maven update rules. 2. Add a `dockerfile` and `docker-compose` manager so the pinned image tags above are auto-tracked. 3. Group updates by ecosystem (one PR per: docker images, npm devDeps, Maven deps) to keep the review surface manageable. 4. Set a sensible auto-merge policy for minor/patch updates on dev-only deps; require manual review for production images and any major bumps. 5. Confirm with the Gitea operator that the Renovate bot has access to the repository — if not, file the access-grant step here. ## Acceptance criteria - [ ] `renovate.json` covers the five production image pins - [ ] First Renovate dependency-dashboard PR appears within 24h of merge - [ ] `docker-compose.prod.yml` comments about Renovate keeping pins current are accurate again (currently stripped in PR #499) ## References - PR #499 — DevOps review (Tobi, [#8352](https://git.raddatz.cloud/marcel/familienarchiv/pulls/499#issuecomment-8352)) - PR #499 — Requirements review (Elicit, [#8356](https://git.raddatz.cloud/marcel/familienarchiv/pulls/499#issuecomment-8356), OQ-1) - PR #499 — comment-strip commit reverting the aspirational language
marcel added the P2-mediumdevops labels 2026-05-11 13:19:26 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-critical
Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.
 P1-high
Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.
 P2-medium
Noticeable improvement; doesn't block anything; schedule opportunistically.
 P3-later
Cosmetic or parking-lot work; fine to stay open indefinitely.
 audit
Read-only audit / assessment work; produces a report rather than changing code
 bug
Something isn't working
 cleanup
Removal of dead code, vague comments, naming violations, and scratch artifacts
 collaboration
We want to extend the family archive to have more collaboration tools
 conversation
descoped
We will do that later
 devops
documentation
README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs
 epic
Marker for epic-level issues that group multiple child issues
 feature
file-upload
legibility
Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction
 notification
person
phase-1: security
Security hygiene — must be done first
 phase-2: container-images
Production-ready multi-stage Docker images
 phase-3: prod-compose
Production compose overlay + Caddy reverse proxy
 phase-4: spring-prod-profile
Spring Boot production configuration profile
 phase-5: backups
Database and object storage backup strategy
 phase-6: deployment-docs
.env.example, DEPLOYMENT.md, runbook
 phase-7: monitoring
Prometheus, Loki, Grafana, Alertmanager
 refactor
Code restructuring without behaviour change
 security
test
ui
UI/UX and accessibility issues
 user
No Label P2-medium devops
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Jens marcel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#500
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?