Fix CI: untrack docs prose, correct two stale frontend specs
wilm has been red for eight consecutive runs across backend, gates and frontend. Three failures, two unrelated causes, neither introduced by the endpoint agent work. docs/ prose (backend + gates): The docs gates detect a published checkout by the ABSENCE of docs/*.md, because docs/ becomes the wiki on that side. DEV-BUILD-TEST.md and PLUGIN-HOOKS.md were committed in unrelated changes, which made CI look like an internal checkout carrying almost no prose. test_there_are_docs_ to_check then failed on `assert 3 > 20`, test_the_map_itself_is_current failed on a generated PROJECT-MAP.md that is correctly untracked, and check-gates-ran.sh failed on the resulting skip - a skipped gate reports green and checks nothing, so it refuses to accept one. The existing .gitignore comment predicted this exactly and was defeated by naming files individually. Untracked both (kept on disk) and replaced the per-file list with docs/*.md so the next authored doc cannot reintroduce it. Scoped to the top level: docs/notes/ prose and docs/openapi.json stay tracked, and the gates only glob docs/*.md. Frontend specs: getEntraDeviceUrls() gained lapsUrl and loaded, but two siteSettings specs still asserted the old two-key shape with toEqual, which is exact-match. The implementation is correct - loaded is what lets a caller distinguish a failed fetch from an unconfigured site, since both read as empty strings - so the specs were brought up to the current shape rather than the return value narrowed. pinnedPanels.spec.js sliced 420 characters from getEntraDeviceUrls() and asserted the finally block appeared inside it. Adding the retry logic pushed finally past that offset, so a correct implementation reported as "the finally is missing". Rebounded the slice to the function's own extent, matching the structural approach already used elsewhere in this file for the same reason. Verified by mutation: renaming the flag in the source fails the test, which also caught that the spec reads plugins/computers/frontend/views/PCDetail.vue and not the .plugins-staged build copy.
This commit is contained in:
benjamin.baker
@@ -1,45 +0,0 @@
|
||||
# ShopDB dev build - quick test
|
||||
|
||||
Two dev builds you can stand up on a Windows box with Docker Desktop. You run
|
||||
one PowerShell script: it checks your dependencies (offers to winget-install
|
||||
anything missing), then PULLS a prebuilt image from GHCR and starts the stack in
|
||||
Docker. Nothing is compiled on your machine - no Node, no npm, no source build -
|
||||
so it works on a box that has only Docker installed.
|
||||
|
||||
## What you need
|
||||
|
||||
- Windows with Docker Desktop running.
|
||||
- Git for Windows (`winget install Git.Git`).
|
||||
- A GitHub login for this private repo/registry already stored on the box. If
|
||||
you have cloned this repo before, or signed in to GitHub in Visual Studio or
|
||||
VS Code, you already have it - the script uses that stored credential
|
||||
automatically. If Docker cannot pull the image, sign in once with
|
||||
`docker login ghcr.io` (use a GitHub username and a personal access token that
|
||||
has `read:packages`), then re-run the launcher.
|
||||
|
||||
## Get the launcher
|
||||
|
||||
You will be sent `Start-ShopDBDev.ps1` directly. Save it anywhere (for example
|
||||
your Downloads folder) and open PowerShell in that folder.
|
||||
|
||||
## Bleeding edge (dev-be)
|
||||
|
||||
powershell -ExecutionPolicy Bypass -File .\Start-ShopDBDev.ps1 -Channel edge
|
||||
|
||||
Comes up at https://localhost:5011. Red DEV badge in the sidebar. Pulls the
|
||||
`edge` image.
|
||||
|
||||
## Stable (main)
|
||||
|
||||
powershell -ExecutionPolicy Bypass -File .\Start-ShopDBDev.ps1 -Channel stable
|
||||
|
||||
Comes up at https://localhost:5001. No DEV badge. Pulls the `stable` image.
|
||||
|
||||
## Notes
|
||||
|
||||
- Both stacks can run at the same time - they use different ports and separate
|
||||
Docker volumes, so they do not collide and each keeps its own database.
|
||||
- Each launch pulls the latest image for the channel, so re-running the launcher
|
||||
is how you pick up a new build. No local rebuild step.
|
||||
- First page load shows a self-signed cert warning (expected for a dev box).
|
||||
- Stop a stack: `docker compose -p shopdb-stable down` (or `shopdb-edge`).
|
||||
@@ -1,45 +0,0 @@
|
||||
# Plugin hooks and contract surface
|
||||
|
||||
Everything a plugin may import from the core lives in `shopdb.api` (ADR-001),
|
||||
versioned by `__contract_version__` (ADR-002). Adding a name is a minor bump;
|
||||
removing one is major. This file records the non-obvious hooks - the ones a
|
||||
plugin author would not guess from the name alone. It is not the full export
|
||||
list; read `shopdb/api/__init__.py` for that.
|
||||
|
||||
## Reversible bulk-import journal
|
||||
|
||||
Contract version 0.30.0.
|
||||
|
||||
A plugin that drives a bulk import - a site asset adoption, an integration sync -
|
||||
records the primitive changes it makes so the whole batch can be reversed later.
|
||||
The journal is import-agnostic: it stores primitive mutations (set a cell, insert
|
||||
a row) tied to a batch id, and a generic undo replays them in reverse. Nothing in
|
||||
core learns what the import means.
|
||||
|
||||
Exposed on `shopdb.api`:
|
||||
|
||||
- `ImportBatch` - one row per applied import. `batchid` is the identity that the
|
||||
approval step, the write, and the undo all reference. `status` is `applied` or
|
||||
`undone`.
|
||||
- `ImportJournalEntry` - one reversible primitive mutation. `operation` is
|
||||
`update` (a cell change, carrying `oldvalue`/`newvalue` so it can be put back)
|
||||
or `insert` (a row this batch created, so undo can delete strictly what the
|
||||
import created).
|
||||
- `BATCH_APPLIED`, `BATCH_UNDONE` - the two `ImportBatch.status` values.
|
||||
- `OP_UPDATE`, `OP_INSERT` - the two `ImportJournalEntry.operation` values.
|
||||
|
||||
What a plugin gets from this, and what it does NOT:
|
||||
|
||||
- A plugin's import UI reads `ImportBatch` to list applied batches (kind, row
|
||||
count, who applied it, when) and offers an "Undo import" per batch.
|
||||
- A plugin does NOT write the journal or run undo through these model imports.
|
||||
The write/undo logic lives with the import writer (see
|
||||
`scripts/site_imports/journal.py`), which records entries in the SAME
|
||||
transaction as the mutation they describe and reverses them conservatively:
|
||||
an `update` is put back only if the cell still holds the value the import
|
||||
wrote (a value a human changed since is left as-is and reported), and an
|
||||
`insert` is hard-deleted only when nothing outside the batch still references
|
||||
the created row.
|
||||
|
||||
The tables are core-owned (migration `7d37_import_batches_and_journal`), so they
|
||||
exist regardless of which plugins are installed.
|
||||
Reference in New Issue
Block a user