173 lines
5.3 KiB
Markdown
173 lines
5.3 KiB
Markdown
# Live Jibo .NET Test Runbook
|
|
|
|
## Goal
|
|
|
|
Run the first real `Jibo -> .NET OpenJibo cloud` test on the Ubuntu machine using the same working certificate and controlled routing that currently work with the Node server.
|
|
|
|
This runbook intentionally avoids introducing Azure, new hostnames, or new robot bootstrap changes during the first live test.
|
|
|
|
For release closeout coverage after the robot is connected, use [regression-test-plan.md](regression-test-plan.md).
|
|
|
|
## Recommended Approach
|
|
|
|
Use the existing Ubuntu networking path and certificate material first.
|
|
|
|
- keep the current controlled Wi-Fi / routing arrangement
|
|
- keep the current Jibo-facing hostnames:
|
|
- `api.jibo.com`
|
|
- `api-socket.jibo.com`
|
|
- `neo-hub.jibo.com`
|
|
- keep the Node server available as a fallback
|
|
- run the `.NET` API with the same cert/key material by converting it to a temporary `.pfx` for Kestrel
|
|
|
|
## Prerequisites On Ubuntu
|
|
|
|
Install or confirm these tools:
|
|
|
|
- `dotnet`
|
|
- `openssl`
|
|
- `curl`
|
|
- `python3`
|
|
|
|
Optional but useful:
|
|
|
|
- `pwsh`
|
|
|
|
`pwsh` is not required anymore for the Ubuntu live test path if you use the bash/python helpers added here.
|
|
|
|
## Certificate Plan
|
|
|
|
The Node server currently uses:
|
|
|
|
- `cert.pem`
|
|
- `key.pem`
|
|
|
|
The `.NET` API can reuse that same material for the test by converting it at startup into a temporary `.pfx`.
|
|
|
|
If your current cert file already includes the working chain, use it as-is.
|
|
|
|
If your chain is separate, pass it as `CHAIN_PEM`.
|
|
|
|
## Step By Step
|
|
|
|
1. On Ubuntu, stop the Node server if it is currently bound to port `443`.
|
|
|
|
2. From the repo root, start the `.NET` cloud using the same cert/key:
|
|
|
|
```bash
|
|
./scripts/cloud/start-dotnet-with-node-cert.sh
|
|
```
|
|
|
|
Optional environment overrides:
|
|
|
|
```bash
|
|
CERT_PEM=/path/to/cert.pem \
|
|
KEY_PEM=/path/to/key.pem \
|
|
CHAIN_PEM=/path/to/chain.pem \
|
|
ASPNETCORE_URLS="https://0.0.0.0:443;http://0.0.0.0:24605" \
|
|
./scripts/cloud/start-dotnet-with-node-cert.sh
|
|
```
|
|
|
|
3. In another terminal, run the prep checklist:
|
|
|
|
```bash
|
|
./scripts/cloud/invoke-live-jibo-prep.sh
|
|
```
|
|
|
|
By default this uses the local HTTP port exposed by the launcher:
|
|
|
|
- `http://localhost:24605`
|
|
|
|
That avoids certificate-name validation issues during preflight.
|
|
|
|
If you want to override it, either of these works:
|
|
|
|
```bash
|
|
BASE_URL=http://localhost:24605 ./scripts/cloud/invoke-live-jibo-prep.sh
|
|
BASEURL=http://localhost:24605 ./scripts/cloud/invoke-live-jibo-prep.sh
|
|
```
|
|
|
|
4. Verify controlled routing from the Ubuntu environment:
|
|
|
|
```bash
|
|
./scripts/bootstrap/test-openjibo-routing.sh
|
|
```
|
|
|
|
5. Power on Jibo and let it connect using the existing controlled network configuration.
|
|
|
|
6. Perform the first live checks in this order:
|
|
|
|
- startup / bootstrap reachability
|
|
- one simple chat turn
|
|
- one joke turn
|
|
|
|
7. After the run, summarize the captured websocket telemetry:
|
|
|
|
```bash
|
|
./scripts/cloud/get-websocket-capture-summary.sh
|
|
```
|
|
|
|
8. Inspect exported fixtures under:
|
|
|
|
- `captures/websocket/fixtures/`
|
|
|
|
Telemetry from the same run should also now be present under:
|
|
|
|
- `captures/http/`
|
|
- `captures/websocket/`
|
|
|
|
9. Import the best fixture into the checked-in websocket fixture set:
|
|
|
|
```bash
|
|
python3 ./scripts/cloud/import-websocket-capture-fixture.py \
|
|
/path/to/exported.flow.json \
|
|
neo-hub-real-jibo-first-chat
|
|
```
|
|
|
|
10. Keep notes on:
|
|
|
|
- whether startup succeeded cleanly
|
|
- which websocket paths connected
|
|
- whether audio stayed pending or finalized
|
|
- whether EOS timing matched expectations
|
|
- whether any unexpected message families appeared
|
|
|
|
## Latest Test Notes To Carry Forward
|
|
|
|
The most recent live round showed that startup and some Q-and-A paths are progressing, but audio-turn reliability is still uneven.
|
|
|
|
Carry these expectations into the next run:
|
|
|
|
- constrained yes/no replies should be tested intentionally because they need special handling and are easy to miss if STT drifts
|
|
- phrases intended to trigger known skills should be repeated using a small, documented wording set so we can separate routing issues from Whisper errors
|
|
- provider-backed placeholder answers are still expected for weather, commute, calendar, news, and similar routes unless that feature path is explicitly implemented
|
|
|
|
For STT during live testing:
|
|
|
|
- prefer runs where `audioTranscriptHint` or other synthetic replay cues are available
|
|
- do not assume local `whisper.cpp` success means the audio pipeline is stable overall
|
|
- if many turns stay pending or `ffmpeg` rejects normalized Ogg files, treat that as a speech-pipeline issue first, not an intent-mapping issue
|
|
- keep the Node server available as the comparison path for yes/no and audio-preprocessing behavior
|
|
|
|
## What To Do If The Test Fails
|
|
|
|
If the robot does not connect or the first turn fails:
|
|
|
|
1. confirm the `.NET` API is actually bound on `443`
|
|
2. confirm the cert presented by the `.NET` API matches the currently working Node cert path
|
|
3. confirm the Ubuntu routing still points Jibo traffic at the same machine
|
|
4. compare the `.NET` websocket capture output with prior Node logs
|
|
5. compare the `.NET` HTTP capture output with prior Node logs
|
|
6. temporarily switch back to Node to confirm the environment still works
|
|
|
|
## Not In Scope For This First Test
|
|
|
|
Do not mix these into the first live run:
|
|
|
|
- Azure deployment cutover
|
|
- new permanent OpenJibo hostnames
|
|
- IaC rollout
|
|
- new device bootstrap edits beyond the already working setup
|
|
|
|
Those are valid next steps, but they should follow the first successful `.NET` live capture, not precede it.
|