anthony.wen/cds-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document ATVM status defaults for live and categorized runs

Browse Source 
Clarify ATVM automation status handling so status requests default to live run data from the automation VM. If no automation is active, fall back to the most recent historical run artifacts and logs.

Also document that categorized runs must always be reconstructed as a single full run across all category batches or cloud sub-runs, rather than reporting only the current or latest batch.

Update:
- atvm/atvm-automation-guide.md
- atvm/AGENTS.md
- atvm/atvm-automation-runs.md
This commit is contained in:
anthony.wen
2026-03-16 17:05:57 -04:00
parent 491bd7748c
commit 99691aca92
3 changed files with 17 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
atvm/atvm-automation-guide.md
View File

@@ -161,12 +161,16 @@ When the operator asks for the status of an ATVM automation run, report in this
Status-report expectations:
- Use the same display layout for every ATVM automation status response regardless of test type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
- Treat a status request as a request for live status by default.
- Use the live automation VM state when available.
- If no automation is currently running, fall back to the most recent historical run artifacts and logs.
- Derive the heading/title from the run `build_name` when available.
- Format every machine entry as `machine-name - STATUS`.
- Put each machine on its own line; never combine multiple machines into one paragraph or comma-separated line.
- Use a separate `Notes` section for failure reasons, anomalies, or operator-relevant context rather than cramming those details into the completed-machine list.
- For categorized runs, reconstruct the whole run across all category batches; do not treat the current live category batch as the full run scope.
- For categorized runs with no active automation, reconstruct the status from the full historical run across all category batches, not only the most recent category batch.
- Always report the status of the entire requested run, even when the runner split execution into multiple category batches or cloud sub-runs.
- Derive completed-machine status from completed spec results already written during the same run.
- Parse all same-run `test-result-*.xml` files, not only machine-named `test-result-atvm*.xml` files.
- When XML filenames are hash-named, extract the machine name from XML contents such as `testsuite file=`, `testsuite name=`, or `testcase name=`.