docs(cloud): Add scloud.yaml schema reference page#627
Conversation
904704f to
7fcb36b
Compare
|
|
||
| ## File location | ||
|
|
||
| The file lives at the root of your project: the workspace root for workspace projects, or the server package directory for single-package projects. When you run `scloud launch`, scloud creates the file in the current directory. |
There was a problem hiding this comment.
Bugbot flags the "workspace root" as incorrect. It says the docs and the CLI default point to the server package directory. Double-check this is correct and whether it can be confusing to users so they might end up putting the file in the wrong place.
|
|
||
| A Serverpod project deployed to Serverpod Cloud has a `scloud.yaml` file at its root. The file links the local project to a Cloud project, optionally pins the Dart SDK used for builds, and lists commands to run before or after each deploy. | ||
|
|
||
| scloud writes the file in two situations: `scloud launch` creates it on first setup, and `scloud project link` updates it when you point your codebase at a different Cloud project. You can also hand-edit it at any time, and scloud preserves your `dartSdk` and hook scripts across later commands. See [How scloud updates the file](#how-scloud-updates-the-file) for the exact per-field rules. |
There was a problem hiding this comment.
"Updates it when you point your codebase at a different Cloud project" implies the file already exists. But scloud project link also creates the file from scratch — for example after scloud project create, or when a developer clones a repo and links it for the first time. Suggest:
scloud project link creates or updates it when you link your codebase to a Cloud project.
|
|
||
| A Serverpod project deployed to Serverpod Cloud has a `scloud.yaml` file at its root. The file links the local project to a Cloud project, optionally pins the Dart SDK used for builds, and lists commands to run before or after each deploy. | ||
|
|
||
| scloud writes the file in two situations: `scloud launch` creates it on first setup, and `scloud project link` updates it when you point your codebase at a different Cloud project. You can also hand-edit it at any time, and scloud preserves your `dartSdk` and hook scripts across later commands. See [How scloud updates the file](#how-scloud-updates-the-file) for the exact per-field rules. |
There was a problem hiding this comment.
A bit weird to start the sentence lowercase.
PR 14 of the Cloud IA rollout. New reference page documenting every field in
scloud.yaml, plus three inbound cross-doc edits and a CLI sidebar position bump. Stacked on #620.Page
cloud_docs/reference/scloud-yaml-schema.mdcovers the file's purpose, where it lives, the full schema with inline YAML examples per field, a complete-example pair (minimal and whatscloud launchwrites), the per-field rules scloud applies on subsequentlaunch/project linkruns, and the validation error messages a reader might search for. Source-of-truth came fromscloud_config_model.dart,scloud_config_io.dart,file_finder.dart,yaml_schema.dart,constants.dart, andproject_files_writer.dart.Cross-doc edits
reference/cli/_category_.jsonposition bumps to 5 so CLI sits after the new schema page at 4.reference/project-id-rules.mdnow points the scloud.yaml mention at the new schema page.concepts/deployment-hooks.mdcross-links to the schema's scripts section for the field types and validation rules. Also rewords the pre-existing warning lead ("pre_deployandpost_deployfailures are not symmetric:" started with inline code) to "Thepre_deployandpost_deployhooks fail asymmetrically:".guides/recover-from-a-failed-deploy.mdcross-links the Pre-deploy hook failure bullet to the schema'spre_deployentry.Test plan
npm run buildpassesproject-id-rules.md,deployment-hooks.md, andrecover-from-a-failed-deploy.mdand confirm they land on the right anchors