Testing CKI Builds externally

How to test CKI builds and submit results

UMB messages for merge request events

Message flow diagram

During the life cycle of a kernel merge request, CKI sends UMB messages to notify other systems about the state of the merge request:

  1. For each variant pipeline, CKI sends an eng.cki.ready_for_test message when builds completed successfully. These messages are tagged with cki_finished=false. They are not sent for pipelines that failed to build.

  2. After CKI testing completes, CKI sends an eng.cki.ready_for_test message with cki_finished=true. This message contains the result of CKI testing after triaging in the status field, which can be success, error, or fail. For example, a build where all FAILed and ERRORed tests have been triaged will be reported as success. For downstream pipelines that care about CKI test status via cki_finished=true, it should be safe to trigger for any builds that report as success or error.

Ready for test message schema

{
    "ci": {
      "name": "CKI (Continuous Kernel Integration)",
      "team": "CKI",
      "docs": "https://cki-project.org",
      "url": "https://gitlab.com/cki-project",
      "email": "cki-project@redhat.com",
      "irc": "Slack #team-kernel-cki"
    },
    "run": {
      "url": "<PIPELINE_URL>"
    },
    "artifact": {
      "type": "cki-build",
      "issuer": "<PATCH_AUTHOR_EMAIL or CKI>",  # Always CKI for merge request testing
      "source_package_name": "<kernel-source-package-name>",
      "source_package_version": "<kernel-source-package-version>",  # optional
      "source_package_release": "<kernel-source-package-release>"   # optional
    },
    "checkout_id": "<KCIDB checkout_id>",
    "tree_name": "<KCIDB tree name>",
    "build_info": [
      {
        "architecture": "<ARCH>",
        "build_id": "<KCIDB build_id>",
        "package_name": "<kernel-binary-package-name>",
        "package_version": "<kernel-binary-package-version>",  # optional
        "package_release": "<kernel-binary-package-release>",  # optional
        "kernel_package_url": "<LINK_TO_REPO>",
        "debug_kernel": bool
      },
      ...
    ],
    "patch_urls": ["list", "of", "strings", "or", "empty", "list"],
    "merge_request": {
      "merge_request_url": "link-or-empty-string",
      "is_draft": bool,
      "subsystems": ["list", "of", "strings"],
      "jira": ["list", "of", "jira", "links"],
      "bugzilla": ["list", "of", "bz", "links"],
      "qa_contacts": ["list", "of", "jira", "qa", "contact", "emails"]
    },
    "branch": "name-of-branch-or-empty-string",
    "modified_files": ["list", "of", "strings", "or", "empty", "list"],
    "pipelineid": <ID>,
    "cki_finished": bool,
    "status": "success|error|fail", # status NOT present if cki_finished is false
    "category": "kernel-build",
    "namespace": "cki",
    "type": "build",
    "generated_at": "<DATETIME_STRING>",
    "version": "0.1.0"
}

For documentation of tree_name, see Standardized CKI KCIDB tree names.

Results messages

Test results should be sent back via UMB to eng.cki.results. Results must be sent in KCIDB v4 format, which has a detailed schema documented by kcidb-io.

Currently, there is no way to expose the results back in the merge request.

Installing merge request kernels

Kernels from merge requests can be installed for testing in Beaker via the kernelinstall task:

<job>
  <recipeSet>
    <recipe ks_meta="redhat_ca_cert">
      <distroRequires>
        <distro_arch op="=" value="x86_64"/>
        <variant op="=" value="BaseOS"/>
        <distro_family op="=" value="CentOSStream9"/>
      </distroRequires>
      <hostRequires/>
      <task name="Kernel installation" role="STANDALONE">
        <fetch url="https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/archive/production/kernel-tests-production.zip#distribution/kernelinstall"/>
        <params>
          <param name="CHECK_CALLTRACE" value="1"/>
          <param name="KERNELARGEXTRAMODULES" value="1"/>
          <param name="KERNELARGINTERNALMODULES" value="1"/>
          <param name="KERNELARGNAME" value="{{ build_info.package_name }}"/>
          <param name="KERNELARGVERSION" value="{{ build_info.package_version }}-{{ build_info.package_release }}"/>
          <param name="KERNELARGPERMREPO" value="{{ build_info.kernel_package_url }}"/>
        </params>
      </task>
    </recipe>
  </recipeSet>
</job>

The distroRequires configuration needs to be adjusted based on the build_info.architecture and tree_name fields.