Catalog metadata and helpers for first-party Silo plugins.
Silo servers consume the generated manifest.json to discover approved plugin
releases, supported platforms, checksums, capabilities, and presentation
metadata. Source plugin repositories remain the authority for implementation
and release artifacts.
Plugin repositories should dispatch plugin_release_published after publishing
a release. Set SILO_PLUGINS_DISPATCH_TOKEN in the plugin repository so it can
call repository_dispatch on Silo-Server/silo-plugins.
silo-plugins uses CATALOG_PUSH_TOKEN to push catalog updates. Reading a
plugin's release metadata and its tagged manifest.json needs no extra
credential: every catalogued plugin repository is public, so the workflow's own
github.token is enough. A plugin has to be public before it dispatches.
To exercise ingestion locally against an existing tagged release, pass the
repository in owner/name form and the exact release tag:
go run ./cmd/update-catalog \
-repo Silo-Server/silo-plugin-metadata-tmdb \
-tag v1.2.23For a private source repository, provide GITHUB_TOKEN through your normal
secret-injection workflow. The command rewrites manifest.json; review or
discard that diff after the check.
go test ./...
go vet ./...
go build ./...Read CONTRIBUTING.md before opening a pull request. Plugin implementation changes belong in the source plugin repository; catalog schema and automation changes belong here.
silo-plugins is licensed under Apache-2.0. See LICENSE.