Docs updates

.github/workflows/deploy.yml

@@ -53,10 +53,6 @@ jobs:
         run: if [ -e kernelci.org/external/kernelci-pipeline/.git ]; then git -C kernelci.org/external/kernelci-pipeline pull origin main; fi
       - name: Update submodule kernelci-api
         run: if [ -e kernelci.org/external/kernelci-api/.git ]; then git -C kernelci.org/external/kernelci-api pull origin main; fi
-      - name: Update submodule kernelci-core
-        run: if [ -e kernelci.org/external/kernelci-core/.git ]; then git -C kernelci.org/external/kernelci-core pull origin main; fi
-      - name: Update submodule kcidb
-        run: if [ -e kernelci.org/external/kcidb/.git ]; then git -C kernelci.org/external/kcidb pull origin main; fi
       - name: Update submodule kci-dev
         run: if [ -e kernelci.org/external/kci-dev/.git ]; then git -C kernelci.org/external/kci-dev pull origin main; fi
 

.gitmodules

@@ -1,15 +1,9 @@
 [submodule "kernelci.org/themes/docsy"]
 	path = kernelci.org/themes/docsy
 	url = https://github.com/google/docsy.git
-[submodule "kernelci.org/external/kernelci-core"]
-	path = kernelci.org/external/kernelci-core
-	url = https://github.com/kernelci/kernelci-core.git
 [submodule "kernelci.org/external/kernelci-api"]
 	path = kernelci.org/external/kernelci-api
 	url = https://github.com/kernelci/kernelci-api.git
-[submodule "kernelci.org/external/kcidb"]
-	path = kernelci.org/external/kcidb
-	url = https://github.com/kernelci/kcidb.git
 [submodule "kernelci.org/external/kernelci-pipeline"]
 	path = kernelci.org/external/kernelci-pipeline
 	url = https://github.com/kernelci/kernelci-pipeline.git

kernelci.org/content/en/components/kcidb/_index.md

@@ -0,0 +1,46 @@
+---
+title: "KCIDB"
+date: 2026-07-16
+description: "KCIDB - The common database for kernel test results"
+weight: 3
+---
+
+KCIDB is the common results database of the KernelCI ecosystem. CI systems
+that build and test the Linux kernel — including KernelCI's own
+[Maestro](/components/maestro), Red Hat CKI, Google syzbot and others — send
+their results here in a unified format, so the community gets one place to
+look at them: the [Web Dashboard](https://dashboard.kernelci.org/).
+
+## How it works
+
+The current KCIDB service is implemented by
+[kcidb-ng](https://github.com/kernelci/kcidb-ng) and consists of a few simple
+pieces:
+
+* **REST API** (`kcidb-restd-rs`) — receives your submissions over HTTPS,
+  authenticated with JWT tokens.
+* **Ingester** — validates each submission against the
+  [KCIDB schema](https://github.com/kernelci/kcidb-io) and loads it into a
+  PostgreSQL database.
+* **LogSpec worker** — analyzes logs of failed builds and tests to
+  automatically identify issues and create incidents.
+
+Once your data is ingested, it shows up on the
+[Web Dashboard](https://dashboard.kernelci.org/) and is available to tools
+like [kci-dev](https://kci.dev/).
+
+> **Note:** KCIDB used to be built on Google Cloud services (Pub/Sub and
+> BigQuery) with a Grafana dashboard. That setup has been replaced by the
+> kcidb-ng REST API described here.
+
+## Submitting results
+
+Want to contribute results from your CI system? Great, we'd love to have
+them! See the [submitter guide](submitting) — it only takes a JSON file and
+a `curl` command.
+
+## Self-hosting
+
+KCIDB-ng can also be deployed on your own infrastructure, together with the
+Web Dashboard if you like. See the
+[self-hosted KernelCI documentation](/components/devops/#kcidb-ng-deployment).

kernelci.org/content/en/components/kcidb/submitting.md

@@ -0,0 +1,190 @@
+---
+title: "Submitter guide"
+date: 2026-07-16
+description: "How to submit build and test results to KCIDB"
+weight: 20
+---
+
+Any CI system that builds or tests the Linux kernel can contribute results
+to KCIDB. You only share what you want to make public — there is no
+requirement to submit private test results.
+
+Submitting is a simple HTTPS POST. No daemons, no cloud accounts, no special
+client tools needed.
+
+## 1. Get in touch
+
+Write to us using any of the [contact channels](/contacts). We will:
+
+* agree on an **origin** — a short string identifying your CI system
+  (e.g. `myci`), used as a prefix in all your object IDs;
+* hand you **JWT tokens** and endpoint URLs for the staging and production
+  instances.
+
+You start on staging, where you can experiment freely, and move to
+production once you are happy with your data.
+
+## 2. Prepare your data
+
+Reports are JSON documents following the
+[KCIDB schema](https://github.com/kernelci/kcidb-io). They can contain five
+kinds of objects: **checkouts**, **builds**, **tests**, **issues** and
+**incidents**. You can submit any of them, in any combination — for example
+only tests, referring to builds submitted by someone else.
+
+All object IDs must start with your origin followed by a colon. Here is a
+minimal but useful report:
+
+```json
+{
+    "version": {"major": 5, "minor": 3},
+    "checkouts": [
+        {
+            "id": "myci:c9c9735c46f5",
+            "origin": "myci",
+            "git_repository_url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git",
+            "git_commit_hash": "c9c9735c46f589b9877b7fc00c89ef1b61a31e18",
+            "patchset_hash": ""
+        }
+    ],
+    "builds": [
+        {
+            "id": "myci:build-1",
+            "origin": "myci",
+            "checkout_id": "myci:c9c9735c46f5",
+            "architecture": "x86_64",
+            "config_name": "defconfig",
+            "status": "PASS"
+        }
+    ],
+    "tests": [
+        {
+            "id": "myci:test-1",
+            "origin": "myci",
+            "build_id": "myci:build-1",
+            "path": "ltp.sem01",
+            "status": "PASS"
+        }
+    ]
+}
+```
+
+For builds we want at least the kernel configuration, build environment
+details and logs; for tests, the results, logs and information about the
+test environment (device type, configuration, etc.). Anything that doesn't
+fit the schema can go into the free-form `misc` field of any object.
+
+### Artifact hosting
+
+KCIDB stores metadata and links, not files. Logs, kernel images and other
+artifacts you reference in your submissions (`log_url`, `config_url`,
+`output_files`...) need to be hosted by you and **publicly available** over
+HTTP(S) — they are linked from the dashboard and downloaded for automatic
+log analysis.
+
+If you are a member of the KernelCI foundation, we will gladly assist and
+can provide file hosting for these materials on our
+[kernelci-storage](/components/kernelci-storage) infrastructure. If not,
+[reach out](/contacts) anyway — whether we can help with hosting is
+something to discuss and decide together.
+
+### Hybrid submissions
+
+You don't have to build kernels yourself. A common setup is a lab that takes
+kernels built by [Maestro](/components/maestro), runs its own tests on its
+own hardware and submits only the test results, with `build_id` pointing at
+the existing Maestro build:
+
+```json
+{
+    "version": {"major": 5, "minor": 3},
+    "tests": [
+        {
+            "id": "myci:test-42",
+            "origin": "myci",
+            "build_id": "maestro:67d409f9f378f0c5986dc7df",
+            "path": "ltp.sem01",
+            "status": "PASS"
+        }
+    ]
+}
+```
+
+Your results then show up on the dashboard right next to the build they were
+run against. The same works the other way around: you can submit builds for
+others to test.
+
+If this describes your lab, also consider connecting it to
+[Maestro](/components/maestro) directly instead of submitting to KCIDB
+yourself. Maestro supports
+[pull labs](/components/maestro/pipeline/connecting-pull-lab): your lab
+polls Maestro for jobs over outbound HTTPS, so it doesn't need to be
+publicly reachable and works fine behind a firewall. For labs testing
+Maestro kernels this is the recommended path — results submitted through
+Maestro keep its node hierarchy consistent, and Maestro takes care of
+forwarding them to KCIDB for you.
+
+## 3. Submit it
+
+Send your report to the `/submit` endpoint with your token in the
+`Authorization` header:
+
+```bash
+curl -X POST \
+  -H "Authorization: Bearer $KCIDB_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d @report.json \
+  https://staging.db.kernelci.org/submit
+```
+
+The response contains a submission ID which you can use to track progress:
+
+```bash
+curl -H "Authorization: Bearer $KCIDB_TOKEN" \
+  "https://staging.db.kernelci.org/status?id=<submission_id>"
+```
+
+The status will go from `ready` to `processed` once the data is in the
+database, or `failed` if it didn't pass schema validation.
+
+> **Note:** the staging instance is occasionally taken down for maintenance.
+> If your submissions fail unexpectedly or nothing shows up, don't spend
+> hours debugging your side — just [contact the sysadmins](/contacts) and
+> we'll sort it out.
+
+Alternatively, [kci-dev](https://kci.dev/) can build the payload and submit
+it for you — handy for scripting or trying things out from a git checkout:
+
+```bash
+kci-dev submit build --origin myci \
+  --kcidb-rest-url https://staging.db.kernelci.org \
+  --kcidb-token $KCIDB_TOKEN \
+  --arch x86_64 --config-name defconfig --status PASS \
+  --log-url https://myci.example.com/logs/build-1.log
+```
+
+It also accepts a complete payload with `--from-json report.json`, and
+`--dry-run` shows what would be submitted without sending anything.
+
+## 4. Watch your results arrive
+
+Staging submissions appear on the
+[staging dashboard](https://staging-dashboard.kernelci.org/), production
+ones on the [main dashboard](https://dashboard.kernelci.org/) — look for
+your origin. You can also monitor arrival from the command line with
+[kci-dev](https://kci.dev/):
+
+```bash
+kci-dev results summary --origin myci \
+  --giturl 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git' \
+  --branch master
+```
+
+Start submitting early: seeing your real data is the fastest way to spot
+what needs tweaking, and we are happy to help along the way.
+
+Once everything looks good, switch your submissions to the production
+endpoint at `https://db.kernelci.org/` and you're done.
+
+For more details see the
+[kcidb-ng submitter documentation](https://github.com/kernelci/kcidb-ng/blob/main/SUBMITTERS.md).

kernelci.org/content/en/components/maestro/_index.md

@@ -1,10 +1,35 @@
 ---
 title: "Maestro"
-date: 2024-05-29
-description: "Maestro API and Pipeline"
+date: 2026-07-16
+description: "Maestro - KernelCI's build and test orchestration"
 weight: 2
 ---
 
+Maestro is KernelCI's native build and test orchestration service. It
+watches upstream kernel trees, builds kernels, schedules tests in the
+connected hardware labs and submits the results to
+[KCIDB](/components/kcidb). It is made of two parts: the
+[API](/components/maestro/api/) (database and Pub/Sub) and the
+[Pipeline](/components/maestro/pipeline) (the services doing the actual
+work).
+
+This documentation is mostly useful for two audiences:
+
+* **Lab owners** who want their hardware to run tests driven by KernelCI —
+  start with
+  [Connecting a LAVA lab](/components/maestro/pipeline/connecting-lab)
+  and see the [platform testing guide](/intro/platform-testing) for the
+  available options.
+* **Self-hosters and contributors** who want to run their own Maestro
+  instance or hack on it — see the
+  [self-hosted KernelCI documentation](/components/devops) along with the
+  [API](/components/maestro/api/) and
+  [Pipeline](/components/maestro/pipeline) sections.
+
+If you are a kernel developer looking for test results, you don't need any
+of this — head to the [Web Dashboard](https://dashboard.kernelci.org/) or
+[kci-dev](https://kci.dev/) instead.
+
 ## API Overview
 
 The Maestro API is a server-side service which provides two main features: a
@@ -80,13 +105,15 @@ and test results in some raw format before they were submitted to the API.
 
 ### Staging
 
-An instance has been set up on `staging.kernelci.org` for testing all pending
-changes.  The Docker logs are available in real-time via a [web
-interface](https://staging.kernelci.org:9088/) for both the API and the
-pipeline.  It also provides some [interactive API
-documentation](https://staging.kernelci.org:9000/latest/docs).  This instance
-is not stable, it's redeployed periodically with all open pull requests from
-GitHub merged together on a test integration branch.
+An instance has been set up for testing all pending changes.  It is not
+stable, it's redeployed periodically with all open pull requests from GitHub
+merged together on a test integration branch.
+
+* [staging.kernelci.org](https://staging.kernelci.org/) - staging control
+  panel
+* [staging.kernelci.org:9000/viewer](https://staging.kernelci.org:9000/viewer) -
+  node viewer
+
 Please check [docs](/components/maestro/api/staging) for more details.
 
 ### Production

kernelci.org/content/en/components/maestro/contrib.md

@@ -8,7 +8,7 @@ weight: 2
 KernelCI core project is open for contributions. Contributions may consist of
 adding new builds, tests and device types as well as features and bugfixes for
 KernelCI core tools.
-When the PR is created, the [KernelCI staging](https://kernelci.org/docs/instances/staging)
+When the PR is created, the [KernelCI staging](/components/maestro/api/staging)
 instance takes care of updating the [staging.kernelci.org branch](https://github.com/kernelci/kernelci-core/tree/staging.kernelci.org).
 In general the branch is updated every 8h and a limited set of builds and tests
 are run on it.