diff --git a/docs/advanced/3_cli/generate-metadata.md b/docs/advanced/3_cli/generate-metadata.md index babbae4d7..89c43e799 100644 --- a/docs/advanced/3_cli/generate-metadata.md +++ b/docs/advanced/3_cli/generate-metadata.md @@ -24,10 +24,11 @@ wmill generate-metadata [folder] [options] | `--skip-flows` | Skip processing flows | | `--skip-apps` | Skip processing apps | | `--strict-folder-boundaries` | Only update items inside the specified folder (requires folder argument) | -| `--rehash-only` | Recompute `wmill-lock.yaml` hashes from on-disk content without any backend round-trip. See [Rehash only](#rehash-only) below. | | `-i, --includes ` | Comma-separated patterns to specify which files to include | | `-e, --excludes ` | Comma-separated patterns to specify which files to exclude | +The `rehash` subcommand (see [Rehash](#rehash) below) rewrites lockfile hashes from on-disk content without any backend round-trip. + ## Arguments | Argument | Description | @@ -90,33 +91,46 @@ wmill generate-metadata -i "f/production/*,f/shared/*" wmill generate-metadata -e "f/test/*,f/drafts/*" ``` -## Rehash only +## Rehash -`wmill generate-metadata --rehash-only [folder]` rewrites `wmill-lock.yaml` hashes directly from on-disk content. It does not contact the backend, does not regenerate scripts/flows/apps, and does not rewrite YAML files — it only recomputes the staleness hashes. +`wmill generate-metadata rehash [folder]` rewrites `wmill-lock.yaml` hashes directly from on-disk content. It does not contact the backend, does not regenerate scripts/flows/apps, and does not rewrite YAML files — it only recomputes the staleness hashes. Use it when: -- **`wmill generate-metadata` flags items as stale that you didn't change.** Common causes: an older CLI wrote the lockfile with a different YAML library or unsorted hash keys, leaving entries that no longer match what the current CLI computes. `--rehash-only` rebuilds those entries from disk so they line up again. -- **Your `wmill-lock.yaml` has duplicate `./`-prefixed entries** (e.g. `./f/foo+__script_hash` next to `f/foo+__script_hash`). These come from past `wmill generate-metadata ./folder` invocations on older CLIs. `--rehash-only` deduplicates them by writing canonical (non-prefixed) keys. +- **`wmill generate-metadata` flags items as stale that you didn't change.** Common causes: an older CLI wrote the lockfile with a different YAML library or unsorted hash keys, leaving entries that no longer match what the current CLI computes. `rehash` rebuilds those entries from disk so they line up again. +- **Your `wmill-lock.yaml` has duplicate `./`-prefixed entries** (e.g. `./f/foo+__script_hash` next to `f/foo+__script_hash`). These come from past `wmill generate-metadata ./folder` invocations on older CLIs. `rehash` deduplicates them by writing canonical (non-prefixed) keys. - **You bootstrapped a long-lived `wmill sync`-managed repo** and want to fill in lockfile entries for items that pre-date the lockfile, without redeploying everything. -Examples: +### Options + +| Option | Description | +| ------ | ----------- | +| `--skip-scripts` | Skip processing scripts | +| `--skip-flows` | Skip processing flows | +| `--skip-apps` | Skip processing apps | +| `-i, --includes ` | Comma-separated patterns to specify which files to include | +| `-e, --excludes ` | Comma-separated patterns to specify which files to exclude | + +### Examples ```bash # Rebuild every lockfile entry from disk -wmill generate-metadata --rehash-only +wmill generate-metadata rehash # Scope to a single folder -wmill generate-metadata --rehash-only f/billing +wmill generate-metadata rehash f/billing + +# Rehash scripts only +wmill generate-metadata rehash --skip-flows --skip-apps ``` -`--rehash-only` is non-destructive: it never touches your scripts, flows, apps, or YAML files. It only writes to `wmill-lock.yaml`. +`rehash` is non-destructive: it never touches your scripts, flows, apps, or YAML files. It only writes to `wmill-lock.yaml`. :::caution Trust, don't verify -`--rehash-only` accepts the on-disk content as canonical without checking it against the backend. Don't use it as a substitute for a regular `wmill generate-metadata` run when you actually want to validate that locks/schemas are up to date. Use it only when you've already confirmed the disk content is what you want and just need the lockfile to stop reporting it as stale. +`rehash` accepts the on-disk content as canonical without checking it against the backend. Don't use it as a substitute for a regular `wmill generate-metadata` run when you actually want to validate that locks/schemas are up to date. Use it only when you've already confirmed the disk content is what you want and just need the lockfile to stop reporting it as stale. ::: -`wmill sync pull` runs an automatic, lighter version of this for items that exist on disk but have no lockfile entry — so for typical pull-then-push workflows you don't need to invoke `--rehash-only` manually. +`wmill sync pull` runs an automatic, lighter version of this for items that exist on disk but have no lockfile entry — so for typical pull-then-push workflows you don't need to invoke `rehash` manually. The auto-fill is skipped under `--json` and `--dry-run` so non-interactive scripts and previews don't mutate `wmill-lock.yaml`. ## Migration from legacy commands