Use the proper configuration (repo scoped)

[gentlementlegen]

          @0x4007 So the configuration is correct and does not require a pull-request as you can see [here](https://github.com/ubiquity/business-development/blob/development/.github/.ubiquity-os.config.yml#L370). However during the run that value was `true` as you can see [here](https://github.com/ubiquity-os-marketplace/daemon-disqualifier/actions/runs/12478009115/job/34824958340#step:3:26). This is probably due to the fact that the run was triggered from another repo where that value is `true`. Not sure how we should handle this scenario.

Originally posted by @gentlementlegen in ubiquity/business-development#103 (comment)

[ubiquity-os-beta]

Note

The following contributors may be suitable for this task:

gentlementlegen

77% Match ubiquity-os-marketplace/command-start-stop#74

[gentlementlegen]

@0x4007 continuing the discussion here to not pollute the other issue.

I think the proper solution is to only run the disqualifier checks within the repo where the event was triggered (not the whole org). This is because we can have repo scoped configurations, which only apply to that specific repo.

[0x4007]

I disagree. There's many repos without much activity and a few with the most so the former would be very unmaintained by the disqualifier.

Instead the disqualifier should build a mapping of every (merged) config to every repo.

Ideally it should use the identical SDK logic the kernel uses to interpret the configs.

[gentlementlegen]

Then we should simply ensure that the disqualifier runs not based on event but time intervals.

Having the disqualifier being able to read configs would just lead to code duplication and complex workflow logic, which should be avoided. Also if the base org does not have the disqualifer but the repo does have it, it means that either way events would only be triggered from this repo and the config would apply to other repos (which should not happen since the org does not have the plugin enabled).

[0x4007]

I'm not convinced. I think the SDK handles most of the config related logic so duplication is fine because it's imported.

[gentlementlegen]

The SDK does not handle the configuration for plugins, only the kernel knows how to read / decode / validate it. Plugins are only aware of their own configuration which is sent by the kernel.

Consider the following scenario:

• the organization does not have daemon-disqualifier enabled
• this repository has daemon-disqualifier enabled

in this case, the daemon-disqualifier will run in the whole org regardless, which I don't think is a desired behavior.