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

3
atvm/AGENTS.md
View File

@@ -115,7 +115,9 @@ When the operator asks for run status, report in this order:
Status details:
- Use the same status display format for every ATVM automation status response regardless of template type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
- Treat a status request as a request for live status by default.
- Use the live run log on the automation VM when available.
- If no automation is currently running, fall back to the most recent historical run artifacts and logs.
- Use the run `build_name` as the heading/title when available.
- Format every machine entry as `machine-name - STATUS`.
- Put each machine on its own line; do not combine multiple machine statuses on one line.
@@ -130,6 +132,7 @@ Status details:
- Include end time and total runtime for completed runs, or elapsed runtime for active runs.
- Include quickest completed test runtime, longest completed test runtime, and average completed test runtime under timing details when they can be derived from the log.
- Make the estimated completion time refer to the entire remaining run, not only the current machine/spec.
- For categorized runs, reconstruct the status of the entire run across all category batches whether the run is still active or only historical artifacts remain.
### Automation Blacklist
Always exclude these machines with `--exclude_partial_match` when building ATVM automation commands.

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=`.

10
atvm/atvm-automation-runs.md
View File

@@ -135,3 +135,13 @@ This file stores run-specific examples only when a run produced a new learning r
- If the requested config file is missing, stop immediately and report the missing filename.
- Do not search the automation VM for alternate config files.
- Do not switch to another config unless the operator explicitly instructs it.
## Run Learning: 2026-03-16 (Status requests default to live view with whole-run historical fallback)
- Observed requirement:
- When the operator asks for ATVM automation run status, they want live status by default.
- If no automation is currently running, the status response must fall back to the most recent historical run.
- For categorized runs, the response must still cover the entire run rather than only the latest category batch or cloud sub-run.
- Action for future runs:
- Treat every ATVM status request as a request for live run status unless the operator explicitly asks for something else.
- If no automation is active, reconstruct status from the most recent historical run artifacts and logs.
- For categorized runs, always aggregate all same-run category batches so the response covers the full run scope.