docs(skills): add the estate deploy-and-test procedure #397

Merged
allan merged 1 commits from docs/estate-testing-skill into release/7.20 2026-10-28 22:34:37 +00:00
Collaborator

Documents the cycle that keeps tripping agents up, as a repo-local skill plus a pointer from the testing doc.

The cycle itself is small - npm run server then sasjs test -t server - but the seed inside npm run server is load-bearing and the failure it produces when skipped looks like a broken deployment:

  • sasjs cbd alone deploys the services and tests but creates no Data Controller configuration. testsetup reads <appLoc>/services/public/settings.sas through the drive API, which makedata creates, so a fresh appLoc gives a 404 and 59 of the 64 test programs fail to complete on setup alone (observed on a new appLoc on 2026-10-28; the same tree then ran 64/64 with 241 assertions passing once seeded).
  • The shipped deploy/makeDataServer.json names ADMIN: AllUsers, which is not a group on the shared estate: the account is in all-users (a call to services/public/getgroups returns it). With a group the account is not in, the seed still reports SUCCESS and every later getdata/stagedata call aborts with ... is not authorised to edit ... in the MPE_SECURITY table.
  • KEEPME decides whether a second seed is possible without redeploying, because makedata deletes itself after a successful run.
  • ERROR lines in the per-program logs are expected - the specs that assert a refusal produce %ABORT CANCEL and the invalid-payload messages they assert on, so the verdict is the JSON counts, not a grep for ERROR.

Also recorded: the server target facts (SASjs Server, real SAS 9, so server branch only), the token-pair credentials the CLI needs, how to point a scratch appLoc target at your own branch instead of replacing the shared app, result paths, and the frontend steps (decrypt sheet-crypto.tgz.gpg, the gitignored .npmrc, rewriting apploc= in dist/index.html, then cbd streams it).

Verification of the documented procedure, run on the estate at release/7.20 (b8eea50):

  • sasjs cbd -t <scratch target>: services deployed, Copying web app files, Web app is available at https://sas.4gl.io/AppStream/DataControllerAgent001
  • streamed page returns 200 with apploc="/Public/app/agent001/dc", and the main.b95c3939c75473c1.js it names serves 200 (8,934,818 bytes) and contains the 7.20 va_parmap code
  • makedata seeded LIBREF DC621835; npx sasjs test -t agent: 64/64 test programs, 241/241 assertions, failed_to_complete 0, completed_with_failures 0

Nothing in the branch touches product code - markdown only, and no credentials, passphrase or customer detail is recorded.

  • agent001
Documents the cycle that keeps tripping agents up, as a repo-local skill plus a pointer from the testing doc. The cycle itself is small - `npm run server` then `sasjs test -t server` - but the seed inside `npm run server` is load-bearing and the failure it produces when skipped looks like a broken deployment: - `sasjs cbd` alone deploys the services and tests but creates no Data Controller configuration. `testsetup` reads `<appLoc>/services/public/settings.sas` through the drive API, which `makedata` creates, so a fresh appLoc gives a 404 and **59 of the 64 test programs fail to complete on setup alone** (observed on a new appLoc on 2026-10-28; the same tree then ran 64/64 with 241 assertions passing once seeded). - The shipped `deploy/makeDataServer.json` names `ADMIN: AllUsers`, which is not a group on the shared estate: the account is in `all-users` (a call to `services/public/getgroups` returns it). With a group the account is not in, the seed still reports `SUCCESS` and every later `getdata`/`stagedata` call aborts with `... is not authorised to edit ... in the MPE_SECURITY table`. - `KEEPME` decides whether a second seed is possible without redeploying, because `makedata` deletes itself after a successful run. - `ERROR` lines in the per-program logs are expected - the specs that assert a refusal produce `%ABORT CANCEL` and the invalid-payload messages they assert on, so the verdict is the JSON counts, not a grep for ERROR. Also recorded: the `server` target facts (SASjs Server, real SAS 9, so server branch only), the token-pair credentials the CLI needs, how to point a scratch appLoc target at your own branch instead of replacing the shared app, result paths, and the frontend steps (decrypt `sheet-crypto.tgz.gpg`, the gitignored `.npmrc`, rewriting `apploc=` in `dist/index.html`, then `cbd` streams it). Verification of the documented procedure, run on the estate at `release/7.20` (`b8eea50`): - `sasjs cbd -t <scratch target>`: services deployed, `Copying web app files`, `Web app is available at https://sas.4gl.io/AppStream/DataControllerAgent001` - streamed page returns `200` with `apploc="/Public/app/agent001/dc"`, and the `main.b95c3939c75473c1.js` it names serves `200` (8,934,818 bytes) and contains the 7.20 `va_parmap` code - `makedata` seeded `LIBREF DC621835`; `npx sasjs test -t agent`: 64/64 test programs, 241/241 assertions, `failed_to_complete 0`, `completed_with_failures 0` Nothing in the branch touches product code - markdown only, and no credentials, passphrase or customer detail is recorded. - agent001
hermes added 1 commit 2026-10-28 22:04:13 +00:00
docs(skills): add the estate deploy-and-test procedure
Build / Build-and-ng-test (pull_request) Successful in 6m56s
Lighthouse Checks / lighthouse (pull_request) Canceled after 19m45s
Build / Build-and-test-development (pull_request) Canceled after 16m16s
ad061946c3
The shared-estate cycle is two npm scripts and sasjs test, but the seed in
npm run server is load-bearing: without it testsetup 404s settings.sas and
59 of the 64 test programs fail to complete, which reads like a broken
deployment. Record the targets, the token-pair credentials, the ADMIN group
the estate actually uses, how to read the results, and the frontend
passphrase steps as a repo-local skill, and point the testing doc at it.
allan merged commit 2e40749052 into release/7.20 2026-10-28 22:34:37 +00:00
allan deleted branch docs/estate-testing-skill 2026-10-28 22:34:37 +00:00
Sign in to join this conversation.