feat(bom): add --hash, and fix the BOM marker breaking YAML
`feat/bom-generator` carried one commit that never landed on master: file
content hashes in the BOM ("v2 with hashes"). The Python rewrite dropped that
capability, so port it forward rather than losing it when the branch goes.
- `--hash` records a short BLAKE2b digest per file. Opt-in, because it reads
every asset in full and that is wasted work for a plain inventory.
- Hashes are streamed in chunks with `hashlib.blake2b`, not `md5` via haveged
imports, and not whole-file reads — these assets run to hundreds of megabytes.
- YAML gains `hash:` after `size:`; Markdown gains a hash column only when
hashes were requested, so the common table stays readable.
Fix a pre-existing bug found while testing: the BOM marker was written as
`; generated by ...`, but `;` is not a YAML comment, so every generated BOM
failed to parse with "mapping values are not allowed here". Now `#`. Verified by
re-parsing output from both the PyYAML path and the built-in fallback writer.
Sizes alone cannot tell you whether an asset changed; a same-length re-render
keeps the byte count identical. That is the gap the hash closes.
This commit is contained in:
+14
-2
@@ -195,11 +195,23 @@ It writes `BOM.yaml` listing every untracked file under `audio/`, `images/`,
|
||||
used for clean output; otherwise a small built-in writer produces the same
|
||||
schema. Neither is required.
|
||||
|
||||
Add `--hash` to record a short content hash per file:
|
||||
|
||||
```sh
|
||||
python3 scripts/tools.py bom --dir . --hash
|
||||
```
|
||||
|
||||
That is how you answer "has this asset changed since the BOM was written?" —
|
||||
sizes stay identical when you re-render a take at the same length, but the hash
|
||||
will not. Hashing reads every asset in full, so it is off by default; when you
|
||||
only want the inventory, leave it out.
|
||||
|
||||
---
|
||||
|
||||
## Conventions
|
||||
|
||||
- `master` is the protected template. Do per-song work on `<song>/master`, and
|
||||
features on `<song>/<feature>`. See `README.md`.
|
||||
- `master` is the shared template. It is intended to freeze once the workspace is
|
||||
finalised; until then, tooling work can land on it directly. Per-song work goes
|
||||
on `<song>/master`, and features on `<song>/<feature>`. See `README.md`.
|
||||
- Binary assets stay out of git; the BOM is how you know what was used.
|
||||
- Keep new tools in `scripts/`, stdlib only, with a `--dry-run` and `--help`.
|
||||
|
||||
Reference in New Issue
Block a user