kernelci / kernelci-pipeline

Modular pipeline based on the KernelCI API
GNU Lesser General Public License v2.1
6 stars 19 forks source link

KernelCI Pipeline

Modular pipeline based on the new KernelCI API.

Please refer to the API design documentation and pipeline design documentation for more details.

Setting up LAVA lab

For scheduling jobs, the pipeline needs to be able to submit jobs to a "LAVA lab" type of runtime and receive HTTP(S) callbacks with results over "lava-callback" service. Runtime is configured in yaml file following way, for example:

  lava-collabora: &lava-collabora-staging
    lab_type: lava
    url: https://lava.collabora.dev/
    priority_min: 40
    priority_max: 60
    notify:
      callback:
        token: kernelci-api-token-staging

The lava-callback service is used to receive notifications from LAVA after a job has finished. It is configured to listen on port 8000 by default and expects in header "Authorization" token value(secret) from LAVA. Mapping of token value to lab name is done over toml file. Example:

[runtime.lava-collabora]
runtime_token = "REPLACE-LAVA-TOKEN-GENERATED-BY-LAB-LAVA-COLLABORA"
callback_token = "REPLACE-LAVA-TOKEN-GENERATED-BY-LAB-LAVA-COLLABORA"

[runtime.lava-collabora-early-access]
runtime_token = "REPLACE-LAVA-TOKEN-GENERATED-BY-LAB-LAVA-COLLABORA-EARLY-ACCESS"
callback_token = "REPLACE-LAVA-TOKEN-GENERATED-BY-LAB-LAVA-COLLABORA"

In case we have single token, it will be same token used to submit job(by scheduler), runtime_token only, but if we use different to tokens to submit job and to receive callback, we need to specify both runtime_token and callback_token.

Summary: Token name(description) is used in yaml configuration, token value(secret) is used in toml configuration.

Setup KernelCI Pipeline on WSL

To setup kernelci-pipeline on WSL (Windows Subsystem for Linux), we need to enable case sensitivity for the file system. The reason being is, Windows has case-insensitive file system by default. That prevents the creation of Linux tarball files (while running tarball service) with the same names but different cases i.e. one with lower case and the other with upper case. e.g. include/uapi/linux/netfilter/xt_CONNMARK.h and include/uapi/linux/netfilter/xt_connmark.h

To enable case sensitivity recursively inside the cloned directory, fire the below command from Windows Powershell after navigating to the kernelci-pipeline directory on your WSL mounted drive.

PS C:\Users\HP> cd D:\kernelci-pipeline 
PS D:\kernelci-pipeline> (Get-ChildItem -Recurse -Directory).FullName | ForEach-Object {fsutil.exe file setCaseSensitiveInfo $_ enable}  

KCIDB setup

Generate Google Credentials key and copy to KCIDB directory

To set up and submit data to KCIDB, we need to get Google Credentials key.

Check here to see how to get Google Credentials Key.

NOTE: This key allows anyone to do anything with the specified Google Cloud project, so keep it safe.

Once you have gotten the Google credentials key file, copy and paste it to data/kcidb

Use the below command to copy the Google credentials file to data/kcidb directory.

$ cp ~/kernelci-production-admin.json  data/kcidb/<your GOOGLE_APPLICATION_CREDENTIALS path>

kcidb docker container will now have /home/kernelci/data/kcidb/kernelci-production-admin.json file.

Now, the user will be able to send data to kcidb using the Google Credentials key.

Get KCIDB_PROJECT_ID

Once Google Credentials key file is generated, the file will have project_id key.

The value of the kcidb_project_id should be set to the env file

echo "KCIDB_PROJECT_ID=<project_id>" >> .env

Get KCIDB_TOPIC_NAME

The default topic name is kcidb_new. Feel free to use a different topic name, as long as the topic exists in your Google Cloud Account.

The value of the kcidb_topic_name should be set to the env file

echo "KCIDB_TOPIC_NAME=kcidb_new" >> .env