Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New landing page for Documentation #406

Merged
merged 3 commits into from
Jul 8, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 33 additions & 27 deletions kernelci.org/content/en/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,30 +11,36 @@ cascade:
path: "/**"
---

Welcome to the KernelCI documentation website. You'll find below a summary of
the overall architecture and pointers to the main sections.

## Overall Architecture

![architecture](/image/kernelci-architecture.png)

The first thing worth noting here is that there are two main parts of the
overall KernelCI architecture:

### [API & Pipeline](api_pipeline)

The top half of this picture shows native services interacting directly with
the API: LAVA test labs, Kubernetes clusters, custom test environments and the
job scheduler. These are referred to as the KernelCI Pipeline in a loose
sense. Such services can be run pretty much anywhere, they are just API
clients with a particular purpose.

### [KCIDB](kcidb)

Other fully autonomous systems producing their own kernel builds and running
their own tests can submit results to
[KCIDB](kcidb), which is a
[BigQuery](https://cloud.google.com/bigquery) database to provide a unified
kernel test reporting mechanism. Please take a look at this blog post for a
comprehensive description: [Introducing Common
Reporting](https://kernelci.org/blog/2020/08/21/introducing-common-reporting/).
Welcome to the KernelCI documentation website.


<div class="container border border-primary rounded p-2">
<h2 class="text-center">
<a href="kernel-community">Kernel Community</a>
</h2>
<p class="text-center">Start here if you are Kernel developer/maintainer
and want to add your tree and tests.</p>
</div>

<div class="container border border-primary rounded p-2 mt-3">
<h2 class="text-center">
<a href="labs">Labs</a>
</h2>
<p class="text-center">Start here if you want to add a lab to run KernelCI tests.</p>
</div>

<div class="container border border-primary rounded p-2 mt-3">
<h2 class="text-center">
<a href="kcidb">KCIDB</a>
</h2>
<p class="text-center">Start here if you want
to contribute your results to the KernelCI common database. KCIDB can receive tests results from any CI system.</p>
</div>

<div class="container border border-primary rounded p-2 mt-3">
<h2 class="text-center">
<a href="architecture">Contributing to KernelCI</a>
</h2>
<p class="text-center">Start here if you want to contribute to KernelCI and learn
more about our <a href="architecture">technical architecture</a>.</p>
</div>
28 changes: 28 additions & 0 deletions kernelci.org/content/en/architecture/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
---
title: "KernelCI Architecture"
date: 2024-07-03
description: "Learn the inner details behind the KernelCI systems"
---

![architecture](/image/kernelci-architecture.png)

The first thing worth noting here is that there are two main parts of the
overall KernelCI architecture:

### [API & Pipeline](../api_pipeline)

The top half of this picture shows native services interacting directly with
the API: LAVA test labs, Kubernetes clusters, custom test environments and the
job scheduler. These are referred to as the KernelCI Pipeline in a loose
sense. Such services can be run pretty much anywhere, they are just API
clients with a particular purpose.

### [KCIDB](../kcidb)

Other fully autonomous systems producing their own kernel builds and running
their own tests can submit results to
[KCIDB](../kcidb), which is a
[BigQuery](https://cloud.google.com/bigquery) database to provide a unified
kernel test reporting mechanism. Please take a look at this blog post for a
comprehensive description: [Introducing Common
Reporting](https://kernelci.org/blog/2020/08/21/introducing-common-reporting/).
17 changes: 17 additions & 0 deletions kernelci.org/content/en/kernel-community/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
---
title: "Kernel Community"
date: 2024-07-03
description: "Adding trees, tests and interacting with tests results"
weight: 2
---

The Kernel Community is the audience of KernelCI. Upstream maintainers and developers, product makers, hardware vendors, etc. are all interested in getting the kernel tested on a variety of scenarios.

> This documentation is still a **WIP**. As we ready new KernelCI for more users the documentation is being improved and expanded.

This section of the documentation shares instructions to:
* [enable kernel testing for your tree/branch](../api_pipeline/pipeline/developer-documentation/#enabling-a-new-kernel-tree)
* [enable specific tests](../api_pipeline/pipeline/developer-documentation/#enabling-a-new-test)
* visualize the results(TBD)

We know that the documentation above may not answer all your questions. We are working to improve it. We ask you to reach out to our mailing list at [[email protected]](mailto:[email protected]) with questions and feedback. We are eager to hear from you!
6 changes: 4 additions & 2 deletions kernelci.org/content/en/labs/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,11 @@ Anyone can connect their test labs to KernelCI. Once a lab is connected to Kerne

It is up to each lab to define whether it will receive specific test configurations or a generic range of test jobs. If the lab is a LAVA lab, for example, the KernelCI [LAVA runtime](../api_pipeline/pipeline/connecting-lab) will generate test jobs for each single test that is configured to run. On the other hand, if a lab is implementing its own runtime (or bridge to Maestro APIs), they may choose to generate the individual test jobs themselves.

If you are interested it just sending the results of test runs in your infrastructure, you should look at sending the data to [KCIDB](../kcidb) - KernelCI common database for results.
If you are interested in just sending the results of test runs in your infrastructure, you should look at sending the data to [KCIDB](../kcidb) - KernelCI common database for results.

There are a few ways labs can be connected to KernelCI. The documentation for connecting labs in the new architecture is evolving as we add labs.

* [Connecting a LAVA lab](../api_pipeline/pipeline/connecting-lab)
* Writing your own bride/runtime using Maestro APIs (TBD)
* Writing your own bridge/runtime using Maestro APIs (doc TBD, see this [GitHub issue](https://github.com/kernelci/kernelci-project/issues/349#issuecomment-2097641023))

We know that the documentation above may not answer all your questions. We are working to improve it. We ask you to reach out to our mailing list at [[email protected]](mailto:[email protected]) with questions and feedback. We are eager to hear from you!