2 Commits

Include renames

Author	SHA1	Message	Date
jklein	8878329f31	ci: publish charts through the shared block in workflow-util/pipelines ... The reusable publish workflow now lives in workflow-util/pipelines and is called pinned to @v3. All 25 thin hulls switch over and our copy is deleted in the same commit: a hull pointing at a deleted file, or an orphaned file nobody calls, would both be worse than the state before. Each hull gains one line, registry-owner: ${{ github.repository_owner }}. The owner used to be derived inside the workflow (#63); as a required input without a default it is evaluated here, in the calling repository, where the value is measured. That is the house rule of pipelines - a shared block never guesses an owner segment - and it keeps the block free of any context semantics. The workflow_dispatch and push triggers of every hull are untouched; after the move the dispatch is the only way to trigger a publish by hand. The Connect host is no longer wired into the block. It reads the repository variable OP_CONNECT_HOST, which the maintainer has set, and fails in its first step naming the variable when it is empty. Documentation follows the same split as the code. The README entry no longer describes a workflow of this repository; it names where the block lives, what each caller owes it, and points at the publish-helm-chart page of that repository's wiki for the reasons behind the upload step, which are no longer ours to keep current. Nothing of them was lost in the move - the upload step's shell body went across unchanged apart from two error messages that name the owner as an input. Also corrected, because the move made them wrong rather than merely stale: - the helm-dependencies.sh entry still counted the local publish workflow among the five places it runs; it is still five, one of them now the shared block, which is why that block names the script as a prerequisite of its callers; - two comments in install-test.yml pointed at publish-helm-chart.yml as a sibling file, one of them for a trap it documented "at length" - that long form is now on the pipelines wiki, and the comments say so; - the hull count read 24, and reusable workflows with secrets: inherit are now confirmed to work across repositories too; - the chart-creation step in CLAUDE.md said the reusable workflow is ours. install-test.yml stays here, with the reason written down (decision 4 on the issue): it is reusable in form but welded to the ci/ fixtures, the exclusion parser and this repository's chart matrix. A block only one repository can use is not shared, only moved. The note is there so the question is not asked again. Fixes #66	2026-10-01 23:01:47 +00:00
jklein	3fa67d55ef	rss-bridge: new chart ... Takes over the four loose manifests in cluster-config/rss-bridge/ as a proper chart, on the current template-chart standard: strict values schema, null-safe helpers, computed limits, replicas/scaleDown, checksum/config, NOTES.txt. Two things deviate from the repo standard on purpose: - The Ingress models host AND TLS secret name per entry instead of the single conventional tls-<release>-<chart>-ingress. The installation this replaces has grown three separate certificates, one per host. Renaming them would make cert-manager issue three new ones and leave each host unreachable until it did - a self-inflicted outage on a deployment that has been up for over a year. Entries sharing a secret name are grouped into one tls entry, and omitting the name falls back to the convention, so consolidating later is a values change. - Requests and limits are decoupled. The old manifest requested 2Gi of ephemeral storage, identical to its limit, reserving two gigabytes for a workload measured at 2.2 MB after fetching all five whitelisted bridges. The request drops to 64Mi; the limit stays at 2Gi. Hardening was verified rather than assumed. The image ships no USER and runs as root by default, but runs fully hardened once its writable paths are provided: uid/gid 33, readOnlyRootFilesystem, all capabilities dropped, seccompProfile RuntimeDefault. The writable paths were found by running the image with a writable rootfs, exercising every bridge and reading its diff layer - /app/cache, /run, /run/php, /var/lib/nginx. /tmp did not show up that way, because PHP's opcache creates its lock file there and unlinks it immediately; it only surfaced when the hardened container died at startup. Stopping at the first writable path would have shipped a chart that cannot start. Probes use the app's own /?action=health, which renders fixed JSON without touching the cache or any remote site, so neither a scraped site going down nor an unwritable cache can restart the pod. Fixes #128	2026-08-23 23:33:23 +02:00