Repository navigation
feat: automatically install opted-in plugin updates at startup - #8
Merged
Merged
Conversation
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
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
Server owners currently need one exact-package approval for every plugin install or update, even after a successful repository build. Opt into automatic tracking with
"auto_approve": truein.source/plugins.json:A per-plugin boolean overrides the manifest default. Ready cached packages install after opting in, and packages prepared during startup can install on that launch. Background checks only queue work for the next normal restart. Existing release pins and exact source/include refs continue selecting versions.
Valid explicit manual installs/rollbacks/uninstalls retain priority for their startup. Changing a content recipe or pin invalidates an older approval and allows the newly selected automatic package to install without an extra restart. Opting out cancels only automatic pending work. Automatic installs retain ownership/local-edit checks and never imply
replace. Approval policy does not change recipe/package identities. Update reference docs and source examples.Evidence
auto_approvefield and no installation without an explicit approval. A changed pin could also leave a stale manual approval blocking the new automatic package for one startup.After: First startup, updates, offline staging, per-plugin overrides, persisted opt-out, valid manual action precedence, changed-pin invalidation, conflicts, source failure/cache reuse, startup timeout, stale snapshots and pinned releases pass.
go test ./...,go test -race ./...,go vet ./...,CGO_ENABLED=0 go build ./cmd/..., formatting/whitespace checks and both generated server manifest validations pass.Merge Danger
Door: two-way
Existing manifests remain manual by default. Update the runtime before enabling the new field. Before reverting to an older runtime, remove the new policy fields and allow the current runtime to cancel automatic pending actions.
Blast Radius: deployment
Opted-in plugins follow configured branches/releases at normal startup. Newer conflicting packages block automatic work until resolved. Explicit rollback/uninstall is honored for its startup; hold the desired state with a pin, policy override, or recipe removal before later automatic checks. Include-only updates continue using existing dependency revision fingerprints, and policy is reloaded before applying persisted actions.