The config reference only shows `http://localhost:4723/wd/hub\` / `emulator-5554` style examples. There is no example anywhere for an authenticated remote hub (vendor capability blocks like `mozark:options.secret`, the `/wd/hub` path requirement, etc.) — the exact scenario a device-farm pitch implies, and the one most real teams need.
Two related gaps found while wiring up a real remote Appium Hub session end-to-end:
- No config docs: had to reverse-engineer the hub vendor's own Swagger docs to write a working `config.yaml` — nothing in Optics' own docs pointed at vendor capability syntax, quoting keys like `"mozark:options"`, etc.
- No secret-handling story: there's no `${ENV_VAR}` interpolation for capability values in `config.yaml`, so any hub secret must be hardcoded in plaintext YAML — and `optics generate` then bakes that same raw secret into the generated pytest/robot source file, which is easy to accidentally commit.
Ask:
- Add one `config.yaml` example with a vendor-capability block and a note on the URL/port requirement.
- Add basic `${ENV_VAR}` interpolation support for capability values.
- Redact anything that looks like a secret/token/password key when `optics generate` serializes capabilities into source.
Found during a real-device (Samsung Galaxy S22, remote Appium Hub) audit of optics-framework 1.10.0.
The config reference only shows `http://localhost:4723/wd/hub\` / `emulator-5554` style examples. There is no example anywhere for an authenticated remote hub (vendor capability blocks like `mozark:options.secret`, the `/wd/hub` path requirement, etc.) — the exact scenario a device-farm pitch implies, and the one most real teams need.
Two related gaps found while wiring up a real remote Appium Hub session end-to-end:
Ask:
Found during a real-device (Samsung Galaxy S22, remote Appium Hub) audit of optics-framework 1.10.0.