)]}'
{
  "commit": "9e9c4de7f76d8a7c080b70e11b871bfc12d7bc99",
  "tree": "bdc2c75e2a8c4f6cedc74d38797fb81fe513e201",
  "parents": [
    "f74437a2747ee98b10c97cd381ba71f38cbe824a"
  ],
  "author": {
    "name": "Christoforos Miliotis",
    "email": "christoforos.miliotis.dev@gmail.com",
    "time": "Wed Jan 17 15:24:12 2024 +0000"
  },
  "committer": {
    "name": "Christoforos Miliotis",
    "email": "christoforos.miliotis.dev@gmail.com",
    "time": "Thu Jan 18 16:02:01 2024 +0000"
  },
  "message": "Stop creating HealthCheckConfig with a dynamically injected plugin name\n\nCurrently, in order to create a `HealthCheckConfig` instance one needs\nto pass the plugin name. The plugin name is injected dynamically when\nthe object is provisioned. The constructor will then create a config\nobject using a plugin config factory with the provided plugin name.\n\nThis in turn means the config object will hold the contents of the\n`plugin.config` file. For any \"core\" healthcheck, ie a healthcheck\ndefined in the healthcheck plugin, this works fine, ie configuration is\nretrieved from the `healthcheck.config` file.\n\nThe problem arises for any external check, ie a check defined in an\nexternal plugin. In that case, the `pluginName` will be the one of the\nexternal plugin. So for a plugin foo, the `HealthCheckConfig` object will\nuse config located in a file foo.config. Here the external plugin\u0027s\nentire config is leaked into the healthcheck config object.\n\nThis is an even bigger problem because it is assumed every plugin\nprovides its config through a `pluginName.config` file, which is not\ntrue. A prime example of this is the pull-replication plugin, its config\nis defined in a `replication.config` file. Therefore, for such cases,\nany configuration defined in the plugin\u0027s config will be silently\nignored.\n\nA major impact of the above problems is that for external checks, we\ncan\u0027t have the \"base\" healthcheck config in the `healthcheck.config`\nfile. By \"base\" here we refer mainly to the `enabled` flag and the\ntimeout, both core features of any healthcheck specification.\nSuch configuration must be defined in the external plugin\u0027s config file.\n\nStop injecting dynamically the plugin name, instead hardcode it to the\nhealthcheck plugin\u0027s name. An additional benefit of this approach is\nthat the HealthCheckConfig will truly be a singleton object, as both\ncore and external healthchecks will use the same instance.\n\nBug: Issue 312895374\nChange-Id: I445ceafb69c74bc60530f25b44aa80e09262c2a7\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1dc143c6f48d26bfd02d96e8ad378c855d73ddbc",
      "old_mode": 33188,
      "old_path": "src/main/java/com/googlesource/gerrit/plugins/healthcheck/HealthCheckConfig.java",
      "new_id": "93cf563198e2271b8d18c79c16dddd7887b23cda",
      "new_mode": 33188,
      "new_path": "src/main/java/com/googlesource/gerrit/plugins/healthcheck/HealthCheckConfig.java"
    }
  ]
}