golem15/summercms
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(34): WR-01 keep summer build working for frameworks before party.Describe

Browse Source 
summer build always emitted party.Describe and []party.Info, so an
application whose framework requirement predates v0.6.0 stopped compiling
once the CLI was updated. The build now checks the party package go list
resolves in the application (a static look for Describe and Info, not a
version compare, since a local checkout reports the previous tag until
it is tagged) and, when they are missing, writes main.go and
plugins.gen.go exactly as before, with a warning to move the framework
to v0.6.0. An unresolvable party package keeps the current sources.
This commit is contained in:
Jakub Zych
2026-10-29 22:03:57 +01:00
parent 9b72439533
commit 07673e4f30
4 changed files with 180 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/architecture/go-modules-and-workspaces.md
View File

@@ -91,7 +91,7 @@ build:
- `PluginInfo`, one `party.Info` per plugin in manifest order: the ID, the Go module and package, the name and description from the plugin's `plugin.yaml` (see [Publishing plugins](../plugins/marketplace.md)), the version and the source. A plugin from the module cache (`go get`) reports its module version and the source `module`. A plugin directory that is its own git repository, such as a submodule, reports `git describe --tags` output like `v0.3.1-4-gabc1234` and the source `submodule`; an uncommitted change does not alter it. A plugin inside the application's own repository has no version and the source `local`. A plugin without `plugin.yaml` has no name or description.
- `FrameworkVersion`, the framework version the application was built against. When `go.mod` or `go.work` points the framework at a local checkout, it is the newest tag reachable in that checkout; otherwise it is the version `go.mod` requires.
The generated `main` publishes both with `party.Describe` before activating the plugins, so the admin can show the installed plugins with `app.Lookup[party.Installed]()`. When the metadata cannot be resolved, `summer build` prints a warning and bakes the IDs only; it never fails a build. A submodule bump or a new framework tag therefore changes `plugins.gen.go`: commit the regenerated file with the bump.
The generated `main` publishes both with `party.Describe` before activating the plugins, so the admin can show the installed plugins with `app.Lookup[party.Installed]()`. When the metadata cannot be resolved, `summer build` prints a warning and bakes the IDs only; it never fails a build. An application whose framework predates `party.Describe` (before v0.6.0) still builds with a newer `summer`: the build checks the framework's `party` package as `go list` resolves it in the application, and when it has no `party.Describe` it writes `main.go` and `plugins.gen.go` as before (imports and `PluginIDs` only), with a warning to move the framework requirement to v0.6.0 or newer. A submodule bump or a new framework tag therefore changes `plugins.gen.go`: commit the regenerated file with the bump.
`build.tags` lists Go build tags that `summer build` (and `summer dev`) passes to `go build` as `-tags=<tag>,<tag>`, printing them as `build tags: …`. Each tag must consist of lower-case letters, digits and underscores; a duplicate is ignored. Framework features that pull in large dependencies sit behind a tag, such as `summercms_s3` for S3 uploads buckets (see [Storage](../services/storage.md#s3-and-s3-compatible-buckets)). `summer plugin:add` and `summer plugin:install` append their entries to the `plugins:` list in place, so the rest of the file, comments and blank lines included, stays as it was. A script that runs its own `go build` must pass the same tags.