cat-shark/pi-commandcode-provider
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ci(tests): run the Oh My Pi compatibility suite as a required check

Browse Source 
tests/test-omp-compat.mjs skipped whenever omp was not on PATH, which
was always the case in CI, so 0.6.1 shipped an import that pi's compat
entrypoint provides but OMP's bundled pi-ai does not (#74).

Add an omp-compat job that installs @oh-my-pi/pi-coding-agent with Bun
and runs the suite with OMP_COMPAT_REQUIRED=1, which turns the skip into
a failure. Add a first phase that loads the extension through
`omp models -e`, the same loader `omp plugin install` validates with;
it fails on the 0.6.1 index.ts and passes with the runtime resolution.
This commit is contained in:
Patrick Wozniak
2026-09-02 10:14:59 +02:00
parent 9b91e5468e
commit caa4e8e274
4 changed files with 57 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
+11
View File
@@ -52,6 +52,17 @@ COMMANDCODE_E2E_PROVIDER_API_KEY_FILE=/path/to/provider-key npm run test:e2e:liv
Use `npm run test:e2e:live:all` with the Go and GOAT file variables to run both subscription transports sequentially. Store keys in a secret manager and export each one to a new mode-`0600` temporary file for the test; never add key files to the repository. Direct `*_API_KEY` variables are intended primarily for protected CI secrets.
### Oh My Pi compatibility
`tests/test-omp-compat.mjs` runs the extension inside a real `omp` binary against a mock Command Code API. It skips locally when `omp` is not on `PATH`; CI installs Oh My Pi and runs it as a required check with `OMP_COMPAT_REQUIRED=1`, so a change that only loads on pi fails CI instead of the next `omp plugin install`.
To run it locally, point `OMP_BIN` at an omp executable (Oh My Pi needs Bun ≥ 1.3.14):
```sh
npm install -g @oh-my-pi/pi-coding-agent
OMP_BIN="$(npm prefix -g)/bin/omp" node tests/test-omp-compat.mjs
```
Before opening a PR, run:
```sh