Nodes offer an update when the signed catalog pins something newer than what's running, and that machinery is fine. The missing step was the one before it: nothing told *us* when upstream shipped. A pin could sit at fedimintd v0.10.0 for months while every node in the fleet correctly and confidently reported "up to date". The reason nothing could tell us is that a manifest records only our mirror — `source.archipelago-foundation.org/lfg2025/fedimintd:v0.10.0` says nothing about the project it was mirrored from. So this adds an optional `app.upstream` block naming the real source, and a script that asks each one what it has released. Running it answers the question that prompted this. Of 58 apps, 28 are behind, including LND v0.18.4-beta against v0.21.2-beta, Bitcoin Core 28.4 against 31.1, and fedimintd/gatewayd v0.10.0 against v0.10.1. Two choices worth stating. An app with no `upstream` block is reported as UNTRACKED rather than skipped — a silent skip is how this stayed invisible, and before this commit all 58 were silently skipped. And a suggestion prefers our own tag variant: telling someone pinned to `postgres:16.13-alpine` that the newest tag is `18.6-trixie` is true and useless, because swapping the base image is a different decision from bumping a version. Five apps are deliberately left untracked (barkd, immich-postgres, indeedhub-minio, lightning-stack, pine-whisper): I could not establish their upstream with confidence, and a wrong `repo` produces a confident wrong verdict, which is worse than an honest gap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
58 lines
1.7 KiB
YAML
58 lines
1.7 KiB
YAML
app:
|
|
id: indeedhub-redis
|
|
name: IndeedHub Redis
|
|
version: "7.4.8-alpine"
|
|
# Where this app comes from, so scripts/check-upstream-releases.py can
|
|
# tell us when the pin below has fallen behind. Without it nothing can:
|
|
# container.image names our mirror, not the project it was mirrored from.
|
|
upstream:
|
|
kind: dockerhub
|
|
repo: library/redis
|
|
description: Redis queue/cache backend for IndeedHub.
|
|
category: community
|
|
|
|
# Hyphen name matches runtime references + the live container (adoption);
|
|
# alias `redis` is the short hostname the api/ffmpeg reach (QUEUE_HOST=redis).
|
|
container_name: indeedhub-redis
|
|
|
|
container:
|
|
image: source.archipelago-foundation.org/lfg2025/redis:7.4.8-alpine
|
|
pull_policy: if-not-present
|
|
network: indeedhub-net
|
|
network_aliases: [redis]
|
|
|
|
dependencies:
|
|
- storage: 1Gi
|
|
|
|
resources:
|
|
memory_limit: 256Mi
|
|
|
|
security:
|
|
# The alpine entrypoint runs as container-root, `find`s /data to chown
|
|
# anything not owned by the redis user, then su-execs to it. Under the
|
|
# orchestrator's --cap-drop=ALL, root cannot traverse the 0700
|
|
# appendonlydir owned by uid 999 without DAC_OVERRIDE (observed
|
|
# crash-looping ~4k restarts on a test node) — CHOWN is what the find's
|
|
# -exec chown needs on adopted legacy data.
|
|
capabilities: [CHOWN, DAC_OVERRIDE, SETGID, SETUID]
|
|
readonly_root: false
|
|
network_policy: isolated
|
|
|
|
ports: []
|
|
|
|
# Named volume matches the live indeedhub-redis-data volume on .228.
|
|
volumes:
|
|
- type: volume
|
|
source: indeedhub-redis-data
|
|
target: /data
|
|
options: [rw]
|
|
|
|
environment: []
|
|
|
|
health_check:
|
|
type: tcp
|
|
endpoint: localhost:6379
|
|
interval: 30s
|
|
timeout: 5s
|
|
retries: 3
|