You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CLAUDE.md still described a bootstrap.py entry point and a standalone
transform-plugins.yml loading mechanism, neither of which exist anymore
(the entrypoint is ogc.bblocks.entrypoint, and plugins load from the
plugins.transforms/plugins.validators keys in bblocks-config.yaml).
Also brought the CI/CD workflow list up to date.
README.md was a 13-line blurb with no usage instructions. Added how to
consume this as a GitHub Action, how to run it locally/via Docker, and
a repository layout overview.
@@ -54,7 +56,7 @@ bootstrap.py Loads plugins from transform-plugins.yml, then delegates
54
56
55
57
- **`validate.py`** — Test validation and HTML/JSON/text report generation. Validators (JSON Schema, RDF/SHACL, semantic uplift) live in `validation/`.
External transform/validator plugins are declared under `plugins.transforms` / `plugins.validators` in `bblocks-config.yaml`:
82
84
```yaml
83
85
plugins:
84
-
- modules: [my.custom.Transformer]
85
-
install:
86
-
pip: my-custom-package
86
+
transforms:
87
+
- modules: [my.custom.Transformer]
88
+
pip: [my-custom-package]
87
89
```
90
+
`transform.py`/`validate.py` install each plugin's pip/npm dependencies into a per-plugin sandbox (`sandbox.py`) and register it (`transformers/plugin.py`, `validation/plugin.py`). Unless `--skip-permissions` is set, the user is prompted interactively before installing/running plugin code (`permissions.py`).
88
91
89
-
`bootstrap.py` loads these before delegating to `entrypoint.py`.
92
+
The legacy standalone `transform-plugins.yml` file is still read as a fallback for `plugins.transforms` (with a deprecation warning) if `bblocks-config.yaml` doesn't declare that key.
|`transform-plugins.yml`|Legacy external transformer plugin loading (deprecated — use `plugins.transforms` in `bblocks-config.yaml`)|
100
103
101
104
## Dependencies
102
105
@@ -106,9 +109,11 @@ plugins:
106
109
107
110
## CI/CD
108
111
109
-
-`build-docker.yml` — builds and pushes Docker image to `ghcr.io/opengeospatial/bblocks-postprocess`on push to master
112
+
-`build-docker.yml` — builds and pushes Docker image to `ghcr.io/opengeospatial/bblocks-postprocess`, triggered on push to `develop` or on `v1.*.*` tags (tag pushes also float the `master` tag)
110
113
-`test-postprocess.yml` — regression tests against live bblocks repos (triggered after Docker build)
111
114
-`validate-and-process.yml` — reusable workflow called by downstream repos to postprocess, commit, and deploy their building blocks
115
+
-`test.yml` — exercises this action's own composite/Docker actions (`full/action.yml`, `postprocess/action.yml`)
116
+
-`upload-to-triplestore.yml` — pushes semantic uplift output to a SPARQL triplestore
This repository contains reusable code to integrate components of a reusable data model (and any reused models that are combined to construct it):
4
-
* JSON schema
5
-
* JSON-LD
6
-
*SHACL
7
-
*test cases
8
-
* examples
9
-
* validation outputs
3
+
A GitHub Action and standalone Python tool that postprocesses [OGC Building Blocks](https://github.com/opengeospatial/bblocks-template) — reusable data models combining:
4
+
5
+
* JSON Schema
6
+
*JSON-LD contexts
7
+
*SHACL shapes
8
+
*test cases and examples
9
+
* validation reports
10
10
* profile declarations
11
-
* associated OAS APIs
11
+
* associated OpenAPI (OAS 3.0) definitions
12
+
13
+
For a given source repository it discovers building blocks, annotates and validates them, generates documentation, performs semantic uplift to RDF, and produces a `register.json` describing the whole collection.
14
+
15
+
## Using this as a GitHub Action
16
+
17
+
Two composite/Docker actions are published from this repository:
18
+
19
+
***`opengeospatial/bblocks-postprocess/postprocess@v1`** — runs the postprocessor itself (Docker action, wraps `python -m ogc.bblocks.entrypoint`). Use this if you just want the annotate/validate/document/register steps.
20
+
***`opengeospatial/bblocks-postprocess/full@v1`** — thin wrapper around `postprocess` with the same inputs; intended to be composed into a larger workflow.
21
+
22
+
Most downstream repos don't call either directly — they instead invoke the reusable workflow:
23
+
24
+
***`.github/workflows/validate-and-process.yml`** — checks out the repo, restores/saves a plugin sandbox cache, runs `full`, commits the generated build output back to the repo, deploys the viewer/docs to GitHub Pages, and (optionally) pushes the semantic uplift to a SPARQL triplestore via `upload-to-triplestore.yml`.
See `postprocess/action.yml` / `full/action.yml` for the full list of inputs (register file location, items directory, base URL, viewer deployment, SPARQL credentials, etc.).
36
+
37
+
## Running locally
38
+
39
+
```bash
40
+
pip install -r requirements.txt
41
+
npm install
42
+
43
+
python -m ogc.bblocks.entrypoint \
44
+
--items-dir _sources \
45
+
--register-file build-local/register.json \
46
+
--generated-docs-path build-local/generateddocs \
47
+
--annotated-path build-local/annotated \
48
+
--base-url https://example.org/bblocks/
49
+
```
50
+
51
+
Run `python -m ogc.bblocks.entrypoint --help` for the full list of flags (`--clean`, `--filter`, `--steps`, `--fail-on-error`, `--skip-permissions`, `--log-level`, ...).
52
+
53
+
### Via Docker
54
+
55
+
```bash
56
+
docker build -t bblocks-postprocess .
57
+
docker run -v /path/to/repo:/workspace -w /workspace bblocks-postprocess [flags]
58
+
```
59
+
60
+
### Local testing with URL mappings
61
+
62
+
Create a `bblocks-config-local.yml` next to your `bblocks-config.yaml` to redirect remote URLs to local files while developing:
63
+
64
+
```yaml
65
+
url-mappings:
66
+
https://example.com/path: /local/path
67
+
```
68
+
69
+
`http_interceptor.py`monkey-patches `urllib`/`requests` to honor these mappings.
0 commit comments