kcidb automatching schema

auto-matching-schema.json

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "status": {
      "type": "string",
      "description": "A regex pattern to match statuses, in the case of tests, ignored when matching a build node."
    },
    "valid_build": {
      "type": "boolean",
      "description": "Indicates if the build is valid, in the case of build type, ignored when matching a test node."
    },
    "tree_name": {
      "type": "string",
      "description": "A regex pattern to match the name of the tree."
    },
    "git_repository_url": {
      "type": "string",
      "description": "A regex pattern to match the URL of the Git repository."
    },
    "git_repository_branch": {
      "type": "string",
      "description": "A regex pattern to match the branch of the Git repository."
    },
    "architecture": {
      "type": "string",
      "description": "A regex pattern to match the architecture type."
    },
    "compiler": {
      "type": "string",
      "description": "A regex pattern to match the compiler used."
    },
    "origin": {
      "type": "string",
      "description": "A regex pattern to match the origin of the build or test."
    },
    "log": {
      "type": "string",
      "description": "A regex pattern used to track log lines. If 'PASS' is in the status, this won't be considered for PASS nodes, only for other statuses."
    },
    "path": {
      "type": "string",
      "description": "A regex pattern used to match paths, in the case of tests, ignored when matching a build node."
    },
    "config": {
      "type": "string",
      "description": "A regex pattern to match the configuration name."
    },
    "platform": {
      "type": "string",
      "description": "A regex pattern to match the platform name."
    },
    "output_file": {
      "type": "string",
      "description": "A regex pattern to match the name of one of the output files."
    }
  },
  "anyOf": [
    {"required": ["status"]},
    {"required": ["valid_build"]},
    {"required": ["tree_name"]},
    {"required": ["git_repository_url"]},
    {"required": ["git_repository_branch"]},
    {"required": ["architecture"]},
    {"required": ["compiler"]},
    {"required": ["origin"]},
    {"required": ["log"]},
    {"required": ["path"]},
    {"required": ["config"]},
    {"required": ["platform"]},
    {"required": ["output_file"]}
  ],
  "description": "This schema defines the structure for the auto-matching configuration, to auto-match incidents to the issue where this configuration is attached. All string fields are regex patterns by default. If a field is not specified, it will match all values. At least one property is required."
}

For now, I think our join conditions could be built to handle NULLs (missing fields). Something like this: COALESCE(issues.test_pattern.status, '%') LIKE tests.status. We could tweak the actual expression for performance, but that's the way, I think.

If there's a way to make queries work on custom sets of conditions, or a universal way to run queries based on any set of conditions, then that'd work. As long as we can properly leverage the DBMS to do the matching and the process is scalable I'm fine with it. But I really think this should come first, because having a matching process that'll get slower as the DB grows is not a solution.

But I really think this should come first, because having a matching process that'll get slower as the DB grows is not a solution.

Agreed.