Skip to content

feat: automatically install opted-in plugin updates at startup - #8

Merged
ShookEagle merged 3 commits into
mainfrom
codex/automatic-plugin-installs
Oct 31, 2026
Merged

ShookEagle merged 3 commits into
mainfrom
codex/automatic-plugin-installs

Conversation

@ShookEagle

@ShookEagle ShookEagle commented Oct 31, 2026 •

Copy link
Copy Markdown
Contributor

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": true in .source/plugins.json:

check → download/build → verify staging → queue automatically → install at normal startup

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

  • Before: Automatic lifecycle regressions failed with the unknown auto_approve field 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.
  • A real public Lilac checkout downloaded, compiled with official SourceMod 1.13.0.7478, and installed into a temporary server directory on the first startup without an approve command.
  • go test ./..., go test -race ./..., go vet ./..., CGO_ENABLED=0 go build ./cmd/..., formatting/whitespace checks and both generated server manifest validations pass.
  • Fresh whole-branch review found no actionable issues. Private server installation still requires rollout and verification on that server.

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.

@ShookEagle
ShookEagle merged commit 5122dc1 into main Oct 31, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant