mode.rs/action.rs/app.rs stayed 100% hand-synced across ~30 TUI
resources with no cross-check, and cloud_worker generation never
touched them. These files are also shared across all services and
hand-edited, so a full-file overwrite would destroy other
resources' content.
Add RustTuiViewGenerator, driven by a new opt-in
extensions.rust-tui-view metadata block per resource, patching
only that resource's marker-delimited region via the new
BaseGenerator._patch_marker_region/generate_view helpers.
Resources without the extension are left untouched, so migration
is incremental. Piloted and rolled out for all of network's
migrated resources; regenerated files matched the hand-written
originals byte-for-byte (mode.rs/action.rs) or by an expected
rustfmt line-wrap (app.rs), and reruns are idempotent.
CI: rust-tui-view reads existing files to find markers, unlike every
other target which only writes new ones, so the generation step needs
the target repo's current content before it runs, not after. Add a
pre-step in playbooks/rust/all.yaml seeding wrk/rust/openstack_tui from
a scratch checkout, and wire rust-tui-view into network's target list in
zuul.d/rust.yaml (the only service with opted-in resources so far).
Change-Id: Ie18663862891a8728a265fef618c175ceee6f79d
Signed-off-by: Artem Goncharov <artem.goncharov@gmail.com>
Artem Goncharov
59fa5a785c