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

Switch ATVM watcher status posts to MS Teams

Browse Source
This commit is contained in:
Anthony Wen
2026-07-27 19:07:50 -04:00
parent 67886174b3
commit 063d13d01a
8 changed files with 107 additions and 90 deletions
Download Patch File Download Diff File Expand all files Collapse all files
atvm/docs/automation/guide.md
+14 -14
View File
@@ -50,7 +50,7 @@ Run ATVM CMC automation tests on the designated automation VM without unintended
- If the operator changes any part of the request before execution, rebuild commands and execute the revised command set.
- Default to watcher-backed execution for every run unless the operator explicitly asks to run without watcher.
- When `--categorize` is used with watcher enabled, treat the watcher as a sequential grouped-run watcher:
- it must post one final Mattermost status per completed categorized group/sub-run
- it must post one final MS Teams status per completed categorized group/sub-run
- it must stay active between grouped sub-runs while the parent categorized request is still running
- it must not stop after the first grouped run simply because one grouped run completed
- if the child build id label does not match the actual host/spec being executed, report the grouped run using the inferred host-based group instead of the raw child build id label
@@ -273,19 +273,19 @@ When asked for one VM or a VM set:
- If monitoring was not requested, run commands and report execution success/failure and any errors.
- If monitoring was requested, do not terminate processes automatically; only terminate if the operator explicitly instructs termination.
## Mattermost Status Posting
## MS Teams Status Posting
- Treat a normal ATVM status request as local-only output by default.
- When the operator asks to send ATVM automation run status to Mattermost, use the local defaults from `/home/aw/code/cds/.env.credentials.local`.
- Default Mattermost variables:
- `MATTERMOST_ATVM_WEBHOOK`
- `MATTERMOST_ATVM_CHANNEL`
- When the operator asks to send ATVM automation run status to MS Teams, use the local defaults from `/home/aw/code/cds/.env.credentials.local`.
- Default MS Teams variables:
- `MS_TEAMS_ATVM_WEBHOOK`
- `MS_TEAMS_ATVM_CHANNEL`
- Treat these as the default destination for ATVM automation run-status posts unless the operator explicitly overrides them.
- Send the final ATVM run status only after the run has fully completed, regardless of whether the run passed or failed.
- Do not send interim or in-progress ATVM run status updates to Mattermost unless the operator explicitly asks for that.
- Use the same ATVM status layout that would be shown to the operator locally when posting to Mattermost.
- Do not send interim or in-progress ATVM run status updates to MS Teams unless the operator explicitly asks for that.
- Use the same ATVM status layout that would be shown to the operator locally when posting to MS Teams.
- Default status template: `/home/aw/code/cds/atvm/docs/automation/status-template.md`
- Do not post to Mattermost unless the operator explicitly asks for the run status to be sent there.
- For categorized execution with watcher enabled, send one Mattermost status per completed categorized sub-run/group after that grouped run fully finishes.
- Do not post to MS Teams unless the operator explicitly asks for the run status to be sent there.
- For categorized execution with watcher enabled, send one MS Teams status per completed categorized sub-run/group after that grouped run fully finishes.
## Status Reporting Format
When the operator asks for the status of an ATVM automation run, report in this order:
@@ -310,7 +310,7 @@ 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).
- Use `/home/aw/code/cds/atvm/docs/automation/status-template.md` as the default template for both local status output and Mattermost status posts.
- Use `/home/aw/code/cds/atvm/docs/automation/status-template.md` as the default template for both local status output and MS Teams status posts.
- The default ATVM status template uses flat bullet-list sections for `COVERAGE:`, `TEST FLOW:`, `FAILURE NOTES:`, and `NOTES:`, and Markdown tables for `SUMMARY:`, `HOSTS:`, and `TIMING:`.
- Order the status sections as `SUMMARY:`, `HOSTS:`, `TIMING:`, `COVERAGE:`, `TEST FLOW:`, `FAILURE NOTES:`, then `NOTES:`.
- Keep `NOTES:` focused on non-failure operator-facing value such as the Currents run URL, real anomalies unrelated to the direct failure text, or material fallback behavior.
@@ -322,7 +322,7 @@ Status-report expectations:
- Do not show total test/failure counts in the `Detail` column. Keep those counts in watcher state and summary logic only.
- For passed hosts, render `Detail` as `completed`.
- For any failed host, keep the `Detail` column compact by showing the failing step plus a short error summary, not the full raw stack trace.
- If richer failure text is available, put the longer trimmed excerpt in `FAILURE NOTES:` so the result stays readable in Mattermost and local status output.
- If richer failure text is available, put the longer trimmed excerpt in `FAILURE NOTES:` so the result stays readable in MS Teams and local status output.
- In `COVERAGE:`, describe the important `cmc-templates.py` command inputs such as template, categorize mode, datastore/config family, config filename, migration style, any real plugin/integration path, and other operator-relevant run options, but do not list target hosts there or include verbose prose scope descriptions.
- Only include coverage fields that the template command actually used. Do not show empty or irrelevant fields such as an integration/plugin path for templates that did not use one.
- If `categorize mode: enabled` is already shown in `COVERAGE:`, do not also repeat `--categorize` under `run options`.
@@ -341,7 +341,7 @@ Status-report expectations:
- If the hostname is not present in `vm-inventory.md`, report the kernel value as `unknown`.
- 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.
- Unless the operator explicitly asks to send the status to Mattermost, print the status only in the local terminal response.
- Unless the operator explicitly asks to send the status to MS Teams, print the status only in the local terminal response.
- 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.
@@ -375,4 +375,4 @@ Status-report expectations:
- Use `Notes` for extra context beyond the machine-specific same-line failure description.
- Base the completion estimate on the full remaining machine count and recent per-machine runtime visible in the run log.
- Make the estimate explicitly refer to completion of the entire remaining run, not only the current machine/spec.
- When the operator also asks to send the status to Mattermost, send this same final status output to the configured Mattermost destination only after the run has fully completed.
- When the operator also asks to send the status to MS Teams, send this same final status output to the configured MS Teams destination only after the run has fully completed.