Clean up ATVM automation examples and standardize status guidance
- keep atvm-automation-examples.md limited to reusable example commands - move example-file role guidance into AGENTS.md and atvm-automation-guide.md - document that all ATVM automation run types use the same status display format - record the status-format rule as a run learning in atvm-automation-runs.md
This commit is contained in:
@@ -108,3 +108,12 @@ This file stores run-specific examples only when a run produced a new learning r
|
||||
- Treat `atvm-automation-examples.md` as reference-only.
|
||||
- Use only the options the operator explicitly requested, plus maintained mandatory blacklist handling.
|
||||
- Do not assume extra example exclusions such as distro filters are desired unless the operator asks for them.
|
||||
|
||||
## Run Learning: 2026-03-12 (Use one status format for all automation run types)
|
||||
- Observed requirement:
|
||||
- The operator wants the same ATVM run status display every time, regardless of whether the run is `e2e`, `systemOS`, `reboot`, or another template.
|
||||
- Changing the display style between run types makes the status harder to scan and compare.
|
||||
- Action for future runs:
|
||||
- Use one consistent ATVM status layout for all automation status responses.
|
||||
- Keep the order the same: build name, completed machines, notes, skipped machines, remaining machines, summary, timing, estimated completion time.
|
||||
- Keep machine entries one per line as `machine-name - STATUS` regardless of test type.
|
||||
|
||||
Reference in New Issue
Block a user