mirror of
https://github.com/nocobase/nocobase.git
synced 2026-10-13 07:47:55 +08:00
chenos
09b95894dd
* docs(skills): split the global Skills into project and installation nocobase-create-app creates a project to develop; nocobase-app-installer installs built NocoBase where it runs — a Hub from its template, or an application's archive — and upgrades it. A Hub is installed, not created, unless the user will develop the Hub's own code. Both Skills carry the same routing table, and a request to install NocoBase on a server with no project makes the agent ask what it is for. nocobase-create-app also says which template to pick and, at the end, how the application reaches production. nocobase-app-installer separates the build machine from the one that runs NocoBase, splits installing into what every installation needs, an archive and a Hub, and covers several installations on one machine. skills/README.md and AGENTS.md describe the split. * refactor(app-installer): stop writing HUB_STORAGE_DIR for a Hub The release carrying the installer also publishes a Hub that reads APP_STORAGE_DIR, so the old name the installer wrote beside it for earlier Hub releases is no longer needed. Installing an earlier Hub is refused with STORAGE_IN_RELEASE. * ci: smoke the Hub template from this checkout on pull requests A pull request can change the installer and the Hub template together, as the move to APP_STORAGE_DIR did, and the Hub smoke job paired this checkout's installer with the published Hub, so it failed until a release. The Quality workflow now starts a local registry from Build's tarballs, tags the packages resolved by tag, and runs the template smoke with the installer and the Hub both from this checkout. The published Hub is still installed daily and on demand by app-installer-smoke.yml, which no longer runs that job on pull requests. The registry steps live in a new local-registry action; the release workflows' verify-create-app is left as it is. * test: cover the app-installer smoke job in the Quality gate test The test runs the gate's shell with every job's result; it now passes the new job's result and checks that a failure of it fails the gate.