Add e2e coverage and lifecycle docs for upgrades#5412
Merged
Conversation
JAORMX
force-pushed
the
upgrade-6-e2e-docs
branch
from
66c9cbf to
e794c49
Compare
github-actions
Bot
added
size/M
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5412 +/- ##
==========================================
+ Coverage 68.82% 68.85% +0.03%
==========================================
Files 634 634
Lines 64422 64422
==========================================
+ Hits 44338 44358 +20
+ Misses 16801 16784 -17
+ Partials 3283 3280 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
JAORMX
force-pushed
the
upgrade-6-e2e-docs
branch
from
e794c49 to
1636922
Compare
github-actions
Bot
added
size/M
JAORMX
requested review from
ChrisJBurns,
amirejaz,
jhrozek,
lujunsan,
rdimitrov and
yrobla
as code owners
6 tasks
JAORMX
force-pushed
the
upgrade-6-e2e-docs
branch
from
1636922 to
0220e77
Compare
github-actions
Bot
added
size/M
JAORMX
force-pushed
the
upgrade-6-e2e-docs
branch
from
0220e77 to
7438634
Compare
github-actions
Bot
added
size/M
Detecting an available upgrade is only useful if users can apply it while keeping their configuration. Add the apply path that the CLI and API will drive. Add upgrade.Applier: it reloads the workload's saved config, re-runs the check on fresh state (so a stale result can never drive an apply), resolves the candidate from the registry, and rebuilds the run config preserving the full user configuration — auth, authz, audit, telemetry, tools filters, volumes, secrets, ports, permission profile, and more — changing only the image, merged env/secrets, and re-resolved registry URLs. New required env vars surface through the injected validator. Crucially, the candidate image is verified and pulled (and the policy gate runs) before the destructive stop/delete/start, so a missing or unverifiable image leaves the running workload untouched — there is no rollback once UpdateWorkload begins. Verification uses the same path as thv run. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
With the Applier in place, expose it to users. This lets CLI users and
API clients apply an upgrade while preserving their configuration,
instead of manually re-running a workload with a new image.
Add a thv upgrade apply <name> command. It runs the check, shows the
candidate image, new env vars, and any permission/transport/network
posture drift, then prompts for confirmation. --dry-run reports the plan
without applying; --env/--secret supply values for newly required
variables; --yes (or a non-interactive shell) skips the prompt and fails
loudly on missing required values; --image-verification mirrors thv run.
Add POST /api/v1beta/workloads/{name}/upgrade, delegating to the same
Applier so all clients share one apply path. The API path is always
non-interactive (detached validator) and sources image verification from
server config; the request body can only supply env/secret values, never
redirect the image or weaken verification. Apply failures return a
sanitized 422 with the detailed cause logged server-side, so secret
references in an error chain are never echoed to the caller.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The upgrade flow spans registry lookup, image verification, and a destructive workload recreate, so it needs end-to-end coverage to catch regressions the unit tests cannot. Add an e2e test that exercises the full flow against real osv-mcp image tags via custom registry fixtures: a workload run from the 0.1.1 entry reports up-to-date, repointing the registry to 0.1.3 makes the check report an available upgrade, and apply recreates the workload on the new image while preserving a user-set env var. A negative spec confirms a raw-image workload reports not-registry-sourced. All thv invocations run under an isolated config/home/data dir so the suite never touches the developer's real registry configuration. Document the upgrade state transition in the workloads lifecycle architecture doc. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JAORMX
force-pushed
the
upgrade-6-e2e-docs
branch
from
7438634 to
a4bfec3
Compare
github-actions
Bot
added
size/M
github-actions
Bot
added
size/M
jhrozek
approved these changes
Jun 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The upgrade flow spans registry lookup, image verification, and a destructive workload recreate, so it needs end-to-end coverage to catch regressions the unit tests cannot. Final slice of RFC THV-0068, local scope.
osv-mcpimage tags via custom registry fixtures: a workload run from the0.1.1entry reports up-to-date; repointing the registry to0.1.3makes the check report an available upgrade;applyrecreates the workload on the new image while preserving a user-set env var. A negative spec confirms a raw-image workload reportsnot-registry-sourced.thvinvocations run under an isolated config/home/data dir, so the suite never touches the developer's real registry configuration.Type of change
Test plan
task test-e2e) — full check→apply flow against real osv-mcp tags + the not-registry-sourced negative path.task lint-fix)Manual: fixtures verified against the real
upgrade.Checker(low → up-to-date, high → upgrade-available candidate:0.1.3). The e2e itself requires a container runtime and runs in CI, not in the dev sandbox.Changes
test/e2e/upgrade_e2e_test.gotest/e2e/testdata/upgrade/registry-{low,high}.jsondocs/arch/08-workloads-lifecycle.mdDoes this introduce a user-facing change?
No — tests and documentation only.
Special notes for reviewers
PR 6 of 6 (final) in the RFC THV-0068 stack; based on #5411. The fixtures use the upstream MCP-registry format (a local file in the legacy ToolHive-native format is rejected by the provider) and mirror the real
osventry's transport/port exactly, differing only by image tag.🤖 Generated with Claude Code