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

fix atvm watcher-backed run launch sequence

Browse Source 
Execute the template step before starting watcher-backed ATVM runs.

- run --template-command synchronously in start-atvm-run.sh
- write template output to /tmp/<build>.launch.log
- stop before watcher/runner startup if template generation fails
- document the corrected wrapper behavior in watcher-service docs
- record the stale specPattern failure mode in automation run learnings
This commit is contained in:
anthony.wen
2026-04-29 12:14:55 -04:00
parent 2832ea4175
commit 9673d769e2
4 changed files with 46 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
atvm/watcher-service/README.md
View File

@@ -57,11 +57,12 @@ Each watcher instance is tied to one requested build name.
Typical workflow:
1. Start the watcher for that run.
2. Start the runner service for that run.
3. The watcher polls the runner log, process state, and `cmcReporter` artifacts.
1. Run the approved `cmc-templates.py` command for that run when one is provided.
2. Start the watcher for that run.
3. Start the runner service for that run.
4. The watcher polls the runner log, process state, and `cmcReporter` artifacts.
- before starting, the helper resets any prior watcher state for the same requested build name so stale cancellation or posted markers do not leak into a new run
4. For non-categorized runs, when the run reaches a terminal state:
5. For non-categorized runs, when the run reaches a terminal state:
- `COMPLETED` or `FAILED`
- build the final ATVM status
- send the status to Mattermost
@@ -72,7 +73,7 @@ Typical workflow:
- do not post
- mark the final state
- exit
5. For categorized runs:
6. For categorized runs:
- detect each grouped sub-run in sequence from the parent run log
- wait for that grouped sub-run to finish
- send one Mattermost post for that grouped sub-run if it reached `COMPLETED` or `FAILED`
@@ -154,6 +155,9 @@ That results in:
The helper also:
- runs `--template-command` synchronously first when one is provided
- writes the template phase output to `/tmp/<build-name>.launch.log`
- exits before watcher/runner startup if the template step fails
- stops any stale watcher instance for that same requested build name
- removes the old watcher state directory for that requested build name
- starts the new watcher with a clean state root for the new run