From 51d782d9649b2b21ad285888645368933c7a8727 Mon Sep 17 00:00:00 2001 From: "anthony.wen" Date: Wed, 18 Mar 2026 08:22:24 -0400 Subject: [PATCH] atvm: resolve automation status from local workflow artifacts Clarify that ATVM automation status requests refer to the local atvm folder workflow and the automation VM at 192.168.3.190, not Cirrus project operations such as the atvm - cypress project. Update the ATVM guide and AGENTS notes to prefer local evidence in this order when reporting status: - active runner processes - live automation VM files - shell history for the last launch command - historical reporter artifacts Record the new run learning in atvm-automation-runs.md so future status requests use the correct source of truth. --- atvm/AGENTS.md | 1 + atvm/atvm-automation-guide.md | 2 ++ atvm/atvm-automation-runs.md | 10 ++++++++++ 3 files changed, 13 insertions(+) diff --git a/atvm/AGENTS.md b/atvm/AGENTS.md index 8016403..adcb718 100644 --- a/atvm/AGENTS.md +++ b/atvm/AGENTS.md @@ -115,6 +115,7 @@ 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 references to the "ATVM automation run" or "automation run" as referring to the local ATVM automation workflow in `/home/aw/code/cds/atvm` and the automation VM at `192.168.3.190`, not to Cirrus project operations with similar names. - 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. diff --git a/atvm/atvm-automation-guide.md b/atvm/atvm-automation-guide.md index 47e1995..361846d 100644 --- a/atvm/atvm-automation-guide.md +++ b/atvm/atvm-automation-guide.md @@ -165,9 +165,11 @@ 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 references to the "ATVM automation run" or "automation run" as referring to this ATVM folder workflow and the automation VM at `192.168.3.190`, not to Cirrus project operations such as the `atvm - cypress` project. - 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. +- Prefer local automation evidence in this order: active runner processes, live automation-VM files, shell history for the last launch command, then historical reporter artifacts. - 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. diff --git a/atvm/atvm-automation-runs.md b/atvm/atvm-automation-runs.md index 7ce53e4..6b13010 100644 --- a/atvm/atvm-automation-runs.md +++ b/atvm/atvm-automation-runs.md @@ -154,3 +154,13 @@ This file stores run-specific examples only when a run produced a new learning r - Add `--ignore_force_shutdown` to every `cmc-templates.py` command unless the operator explicitly asks not to use it. - Default plugin-bearing ATVM automation commands to `--use_specified_plugin iscsi`. - Only switch away from `iscsi` when the operator explicitly requests `fc`, `both`, or another applicable override. + +## Run Learning: 2026-03-18 (ATVM status requests must resolve from the local ATVM workflow, not Cirrus project operations) +- Observed failure mode: + - Interpreting "status of the ATVM automation run" as a request about Cirrus project operations can return the wrong source entirely. + - The operator uses "ATVM automation" to mean the automation contained in the local `atvm` folder and the corresponding automation VM workflow. +- Action for future runs: + - Resolve ATVM status requests from the local ATVM workflow first. + - Check the automation VM at `192.168.3.190` for live runner processes and live files before looking at historical artifacts. + - If no automation is active, reconstruct the most recent historical run from the automation VM shell history and reporter artifacts. + - Do not use Cirrus project operations such as `atvm - cypress` as the source for ATVM automation status unless the operator explicitly asks for project-operation status.