cki_tools.cki_notifier

External testing is triggered via CKI notifier messages.

The service consumes DataWarehouse checkout notifications from RabbitMQ and publishes ready-for-test messages to Kafka (kafka.tx.cki.ready-for-test) for External testing.

The notifier can be deployed locally by running

python -m cki_tools.cki_notifier

Configuration via environment variables

Message routing

flowchart TD
    msg[DataWarehouse AMQP message] --> validate[Validate checkout]
    validate --> route{Status}

    route -->|build_setups_finished| pre_test[Pre-test ready-for-test]
    route -->|ready_to_report| post_test[Post-test ready-for-test]
    route -->|checkout_issueoccurrences_changed| retriage[Post-test on fail->pass only]

    pre_test --> kafka[Publish to kafka.tx.cki.ready-for-test]
    post_test --> kafka
    retriage --> kafka

Incoming messages must have object_type: checkout. The diagram shows the happy path; messages that fail validation or do not match a routing rule are ignored (see Filtered and ignored messages).

Supported status values:

unknown status and the race condition

unknown is used when the message does not name a checkout stage explicitly, for example manual CLI runs or out-of-draft MR notifications. The notifier loads the checkout from DataWarehouse and uses misc.ready_to_report or misc.notification_sent_build_setups_finished to choose post-test or pre-test.

For ready_to_report and build_setups_finished, DataWarehouse may emit the message before the matching misc flags are persisted. The notifier trusts the message status in that case instead of waiting for the flags to appear in DataWarehouse.

Issue occurrence updates

After a checkout reaches ready_to_report, DataWarehouse may send checkout_issueoccurrences_changed when triage changes (waive, unwaive, regression, and so on). The notifier sends another post-test message only when all of the following hold:

• checkout misc.ready_to_report is true (initial report already happened)
• message misc.checkout_outcome_changed is true (pass/fail outcome flipped; set by DataWarehouse in top-level message misc)
• the current overall test status is not fail or error (no pass→fail regression after a prior success notification)

Retriage that does not change the overall outcome, and pass→fail regressions, are ignored.

Post-test message status is derived from cki_lib.kcidb.checks.compute_overall_status (success, fail, or error).

Filtered and ignored messages

Before routing, messages are dropped when:

• the status is unsupported or object_type is not checkout
• the checkout is retriggered (object.misc.retrigger) or not from origin redhat
• the checkout is invalid, has no builds, or is stale (merged MR, or head pipeline no longer matches the MR)

Any other status that does not match the routing rules above is ignored as well.

Manual triggering

Messaging can also be manually triggered via the command line. First, make sure to have the required environment variables above configured correctly. Then, the sending of CKI notifier messages can be triggered with

CKI_LOGGING_LEVEL=INFO \
  CKI_DEPLOYMENT_ENVIRONMENT=production \
  python3 -m cki_tools.cki_notifier \
  --status STATUS \
  --checkout-id CHECKOUT_ID

• STATUS can be build_setups_finished, ready_to_report, checkout_issueoccurrences_changed, or unknown. It represents the checkout stage, which determines whether testing has finished and whether test results are included. Use unknown to rely on the DataWarehouse checkout stage.
• CHECKOUT_ID is the KCIDB checkout id (e.g. redhat:12345).

Manual runs do not pass message misc, so --status checkout_issueoccurrences_changed will not match the issue-occurrence routing rules above unless the message body is constructed with misc.checkout_outcome_changed.