* feat(chart): support referencing a pre-existing Secret via existingSecret
Add an existingSecret value to the k3s chart so operators can supply a
cluster-managed Secret instead of letting the chart generate one.
- existingSecret non-empty: skip rendering secret.yaml; Deployment envFrom
references the named Secret; checksum/env-secret annotation omitted (the
chart does not promise to roll on external Secret content changes).
- existingSecret empty: behavior unchanged (chart creates <release>-env and
references it; full backward compatibility).
- When existingSecret is set, .Values.env.* required validations are skipped
via the conditional render (no conflict detection with env.*).
- No per-key mapping (still envFrom), no lookup/verification of the external
Secret, no new NOTES.txt/README — the chart's documentation surface is left
as-is.
Verified with helm template in both modes.
Closes#595
Co-Authored-By: Claude <noreply@anthropic.com>
* test(chart): assert envFrom resolves to envSecretRefName for existingSecret
The k3sAssets guard asserted envFrom referenced metapi.envSecretName, but the
existingSecret feature renamed the envFrom binding to metapi.envSecretRefName
(secretRef.name falls back to the helper when existingSecret is unset). Update
the assertion to match and pin the new existingSecret branch with guards on the
envSecretRefName define and the .Values.existingSecret branch in _helpers.tpl.
Co-Authored-By: Claude <noreply@anthropic.com>
* docs(k3s): document existingSecret mode, required keys, and roll caveat
Add a dedicated section to the k3s update-center doc covering the chart's
existingSecret value: the chart-managed Secret vs an operator-supplied one, the
fixed 11 keys the external Secret must provide, and the behavioral change that
the checksum/env-secret auto-roll on Secret change is omitted under
existingSecret (operators must drive rollouts via Reloader or manual restart).
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
The update center already allowed manual Docker tag deploys, but operators
still had to know and paste dev or branch tags by hand. This change keeps the
stable Docker Hub candidate as the main path while automatically surfacing the
most recent non-stable tags and their digests for one-click deployment.
Constraint: Stable Docker Hub discovery must remain the default candidate path
Constraint: Existing deploy API and helper protocol should stay unchanged
Rejected: Promote dev tags into the primary stable candidate slot | would blur stable and experimental release semantics
Rejected: Add a brand new backend deploy endpoint for recent tags | existing targetTag/targetDigest deploy path already covers the need
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep stable and recent non-stable Docker tag discovery distinct unless product semantics deliberately change
Tested: Focused vitest for update-center services/routes/UI, npm run typecheck, npm run repo:drift-check, npm run build:web, npm run docs:build, git diff --check
Not-tested: Full npm test remains red because tmp/sub2api frontend suites are still broken in this repo snapshot
The update center previously surfaced stable Docker Hub candidates but
left dev and branch-tag rollouts stranded in SSH and Helm commands.
This adds a repo-native manual Docker tag entrypoint in Settings so
operators can deploy dev, branch, temporary, or sha tags through the
existing helper flow without changing the backend deploy contract.
Constraint: Keep the existing helper API and digest-aware Helm contract unchanged
Constraint: Preserve stable Docker Hub candidate discovery for default reminders
Rejected: Expand automatic Docker Hub discovery to all branch tags | would blur stable release reminders with operator-only rollout targets
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep automatic candidate detection stable-first; manual tag deploy is the escape hatch for non-stable tags
Tested: update-center focused vitest suite; typecheck; build:web; docs:build; repo:drift-check
Not-tested: Full npm test remains red due to unrelated tmp/sub2api frontend suites and an existing firstByteTimeout unhandled error
* add k3s update center
* fix update center status timeouts
* Polish update center settings UI
* Document k3s update center
* Refocus update center docs for users
* Clarify k3s migration path in docs
