Deployment View

Deployment View

• Environments: GitHub-hosted ubuntu-latest runners (for registration/ dashboard/escalation logic); self-hosted runners labeled vm-provisioner (Linux and/or Windows, one per provisioning host) for VM-provisioning workflow dispatch; self-hosted runners labeled standards-review-local for compliance re-checking; the self-hosted Windows/Ubuntu LabVIEW VM runners this engine itself provisions, once built and registered (consumer-facing build/test capacity, a distinct concern from the vm-provisioner host that builds them).
• Nodes: VirtualBox VMs provisioned by this engine (Windows 11 + LabVIEW/ VIPM: single-VM lifecycle, validate -> create-vm -> install-vipm -> install-labview -> register-runner; this draft does not establish fresh lifecycle proof, and runner-registration proof remains open under VITechnologies/projectbuddy#110; Ubuntu 24.04 + LabVIEW/VIPM: snapshot-based appliance lifecycle -- a base snapshot, an operator-activated snapshot reached only after a human completes interactive activation at an operator console gate, and an intended package-ready snapshot that would be proven by actually building and verifying a signed .vip artifact. Every phase of this lifecycle previously failed immediately via an unconditional "Validate Dispatch Contract" step (no if: guard) calling .github/scripts/validate-vm-provisioning-dispatch.py, a genuinely generic script dropped during the original engine extraction -- this workflow had zero total runs, ever, on either VITechnologies/projectbuddy or svelderrainruiz/projectbuddy before v0.3.28 restored the missing script. Dispatch-proven as of v0.3.28: the restored script's own phase/UUID/path/port validation logic now reliably passes a validate-phase dispatch and proceeds into the real dry-run adapter plan (the reproducible mechanism is the restored script's own code, verifiable via provision-ubuntu-vm.yml re-dispatch any time -- a one-off historical run ID is not cited here as the proof, consistent with this SRS's own evidence-citation principle; one real validate-phase dispatch did confirm this live the same day the script was restored). package-build remains blocked by design, not by a missing file: it calls vm/ubuntu-labview/build-vip-package.sh, which hardcodes a real VI-Technologies project and is deliberately consumer-vendored, never part of the generic engine (VITechnologies/projectbuddy#62); the intermediate phases (provision-public, complete-activation, etc.) have not yet each been individually re-dispatch-proven the same way the validate phase has; the physical host machine running the standards-review-local self-hosted runner (same host already running the VITechnologies/SandboxSBOMReporting runner, as a separate, independently-registered runner instance).
• Runtime dependencies: NI LabVIEW (on provisioned VMs, activated only via human-driven interactive steps, never automated -- see REQ-018 in Software-Requirements-Specification) + VIPM (human-activated on Windows; on Ubuntu-LabVIEW, VIPM itself is activated non-interactively via vipm activate --direct-vipm-io as a deliberate, narrower automated exception, invoked unconditionally whenever a VIPM env file is supplied -- this is not actually gated on LabVIEW's own activation state at runtime, only on an operator convention documented in the phase's usage text -- see REQ-032 in Software-Requirements-Specification); Docker (for the containerized pipelines); gh CLI + GitHub Actions (throughout); PowerShell 7+ and Python 3.11+ (cross-platform script runtime); VirtualBox + VBoxManage (VM lifecycle control); pywinrm (guest command dispatch for the Windows family).
• Active verification, not passive status mirroring: vm-fleet-status.yml independently re-derives each tracked VM's real GitHub Actions runner registration and VirtualBox power state on a 30-minute schedule, rather than trusting runner-inventory.json's own self-logged status -- deliberately designed this way after a live incident where a self-reported "success" masked a runner registered under the wrong name (REQ-020 in Software-Requirements-Specification). This requires a consuming fork's own real, committed runner-inventory.json; in this public engine repo itself, where no real inventory is ever committed by design, the schedule finds nothing to verify and cleanly no-ops rather than failing (live-verified: VITechnologies/projectbuddy run 42338120277, success, empty matrix). The fork (svelderrainruiz/projectbuddy) hits a different, distinct gap on the same schedule: it has no vm-provisioner-labeled self-hosted runner registered at all (only standards-review-local), so each scheduled run queues and GitHub cancels it before it ever starts -- the same root cause as the already-documented standards-review-local/ standards-compliance-recheck.yml pattern, just for a different runner label and workflow, and not yet disclosed anywhere for this specific workflow before now.