diff --git a/docs/deployment/deploy-prep/2026-11-12-gates-52-131/README.md b/docs/deployment/deploy-prep/2026-11-12-gates-52-131/README.md new file mode 100644 index 00000000..314631f3 --- /dev/null +++ b/docs/deployment/deploy-prep/2026-11-12-gates-52-131/README.md @@ -0,0 +1,144 @@ +# Deploy prep: site-script fixes for Gitea #52 and #131 + +**Prepared:** 2026-11-12. **Not applied** to DEV or QA. Applying it is a deploy and needs the owner's approval. + +**Where the facts come from:** a read-only export of DEV vd03 and QA vq03 taken at 2026-11-12 ~23:10 EST. The export used `template list|get --detail`, `shared-script list`, `api-method list|get`, `instance list` and `instance diff`, and nothing was written. + +- **DEV** runs DisableLogin, so any credentials work. +- **QA** has login enabled. It authenticates against the box-local GLAuth (`ScadaBridge-LDAP` service), so the export used the documented `multi-role` test user there. The username and password were passed through environment variables, never on the command line. + +**Validated:** on the docker rig (main binary, which includes `dd4f1c2a`). See [Rig evidence](#rig-evidence). + +## Files + +| Path | What | +|---|---| +| `original/CvdReactor.ProcessRecipeDownload.cs` | The live body of CvdReactor script 4. It is byte-identical on DEV and QA. **Rollback body.** | +| `original/TestMesMachine.AlarmStatus.cs` | The live body of DEV TestMesMachine script 42. **Rollback body.** | +| `original/*.meta.json` | Each script's other fields: trigger, parameters, return definition, lock and timeouts. | +| `fixed/CvdReactor.ProcessRecipeDownload.cs` | Changes one line: `Children["DelmiaRecv"]` becomes `Children["DelmiaReceiver"]`. | +| `fixed/TestMesMachine.AlarmStatus.cs` | Changes three `a.Severity` reads to `a.Priority`. It is byte-identical to `ALARM_CODE` in `docker/seed-mes-test-machine.sh` at `dd4f1c2a`. | +| `apply.sh` | Takes `check`, `apply` or `rollback` and a gate number (`52` or `131`). Details below. | + +### What `apply.sh` does + +- **`check`** only reads. +- **`apply` and `rollback`** refuse to touch a script unless its live body is byte-identical to the expected file. +- **Metadata:** they re-send every metadata field. `template script update` *replaces* the parameter and return definitions, so a bare `--code` update would wipe them. They then read the fields back and compare them. +- **Deploy:** they deploy the affected instances. `--no-deploy` skips this step. + +## Inventory (live, 2026-11-12) + +The export searched every template script and inbound API method on each env for `Children["…"]` names that aren't compositions, and for `.Severity` reads on a `ScriptAlarm`. There are no shared scripts on either env. Every instance's `instance diff` reports `isStale=false`, so the deployed scripts are the template bodies listed below. + +| Env | Template / script | Problem | Instances to redeploy | +|---|---|---|---| +| DEV vd03 | `CvdReactor` (1) / `ProcessRecipeDownload` (4) | `Children["DelmiaRecv"]`. The only composition is `DelmiaReceiver`. **#52** | Z28061 (1), Z28062 (2), Z28061Sim (8) | +| QA vq03/vq04 | `CvdReactor` (1) / `ProcessRecipeDownload` (4) | Same body, byte for byte. **#52** | Z28061 (1), Z28062 (2), Z28063 (9), Z28064 (11), Z28065 (12), Z28066 (13), Z28067 (10), Z28068 (14), Z28069 (15) | +| DEV vd03 | `TestMesMachine` (30) / `AlarmStatus` (42) | Reads `a.Severity` in 3 places: the MinSeverity and MaxSeverity predicates and `Severity = a.Severity`. **#131** | SBTEST01 (9), SBTEST02 (10) | +| QA | — | **No #131 work.** QA has no TestMesMachine. Its `CvdReactor.AlarmStatus` (39) is a stub that returns `Alarms = []`. No other script calls `Alarms.*`. | — | + +Every other `Children[...]` reference on both envs resolves: TestMesMachine's `LeftMESReceiver`, `RightMESReceiver` and `DelmiaReceiver`. + +The inbound methods `SimpleAlarmStatusRequest` and `AlarmStatusRequest` only *pass* `MinSeverity`/`MaxSeverity` to the site script as arguments. They never read a `ScriptAlarm`, so they need no change. + +Two corrections to the issue texts: + +- **#131: the old body still compiles on main.** `ScriptAlarm.Severity` still exists after `dd4f1c2a`; it now holds the banded value. So the deployed scripts keep compiling and running on the new binary, but they return **wrong numbers and inverted filters** (rig evidence, Q1–Q3). The compile problem runs the other way: the **fixed** body references `ScriptAlarm.Priority`, which the deployed binaries don't have. Neither DEV `424db155` nor QA `b3021e7c` contains `dd4f1c2a`. On the rig, a body with an unknown `ScriptAlarm` member saves fine, because save does no compile check. Deploying it is refused with `Pre-deployment validation failed: … ScriptCompilation`. +- **#131: DEV's CvdReactor has no `AlarmStatus` script at all.** So `SimpleAlarmStatusRequest` for Z2806x answers "not supported". The `CvdReactor.SimpleAlarmStatus`/`AlarmStatus` pattern in `docs/plans/2026-06-30-mes-alarm-status-api.md` §5.3 is a doc pattern and is not deployed anywhere. If it is ever authored, write it with `a.Priority`. + +## Order relative to the ScadaBridge binary deploy + +### #52: any time, independent of the binary + +The fixed body uses only APIs that the DEV and QA binaries already run, because the current body already uses them. The fix is one string literal. + +- **Recommended:** apply it in the same window as the next binary deploy, so the instances redeploy only once. +- **Z28061 on the wonder boxes is also used by another team.** Agree a slot before redeploying it; the redeploy restarts the instance actor. Z28062 is the safe one to test against. + +### #131: DEV only, with or after the binary that contains `dd4f1c2a`, in the same window + +1. Deploy the new ScadaBridge binary to central and site. +2. Immediately run `apply.sh apply 131`, before MES alarm traffic is trusted again. + +**Applied before the binary:** the template saves, but the SBTEST instance deploys are refused by pre-deployment compilation. The site keeps the old body, which is harmless. Run `apply.sh rollback 131 --no-deploy` to put the template back. + +**Binary without this step:** MES alarm-status output for SBTEST01/02 changes. Values come back banded (800→250, 300→750, 700→500), and the MinSeverity and MaxSeverity filters select the wrong alarms. + +**Alternative:** re-run `docker/seed-mes-test-machine.sh` against vd03. It produces the same AlarmStatus body. But it also rewrites the inbound methods `SimpleAlarmStatusRequest` and `AlarmStatusRequest` and every other TestMesMachine script, so diff those first. `apply.sh` changes only the one script. + +## Apply (from the Mac, after approval) + +```bash +cd ~/Desktop/ScadaBridge && dotnet build src/ZB.MOM.WW.ScadaBridge.CLI # apply.sh uses bin/Debug/net10.0/scadabridge (override: SB_CLI) +P=docs/deployment/deploy-prep/2026-11-12-gates-52-131 + +# DEV (DisableLogin: any credentials) +export SCADABRIDGE_URL=http://wonder-app-vd03.zmr.zimmer.com:8085 SCADABRIDGE_USERNAME=x SCADABRIDGE_PASSWORD=x +bash $P/apply.sh check 52; bash $P/apply.sh apply 52 # any time +bash $P/apply.sh check 131 # after the dd4f1c2a+ binary is up on DEV… +bash $P/apply.sh apply 131 # …in the same window + +# QA (login enabled; box-local GLAuth; export the password from a prompt, not argv) +export SCADABRIDGE_URL=http://wonder-app-vq03.zmr.zimmer.com:8085 SCADABRIDGE_USERNAME=multi-role +read -rs SCADABRIDGE_PASSWORD && export SCADABRIDGE_PASSWORD +bash $P/apply.sh check 52; bash $P/apply.sh apply 52 # 9 instances; vq03 is the active central +``` + +**Manual equivalent:** + +1. Update the script with `scadabridge template script update`, passing every flag: + - `--id