mirror of
https://github.com/discourse/discourse.git
synced 2024-11-25 10:20:58 -06:00
a72dc2f420
Previously, problem checks were all added as either class methods or blocks in AdminDashboardData. Another set of class methods were used to add and run problem checks. As of this PR, problem checks are promoted to first-class citizens. Each problem check receives their own class. This class of course contains the implementation for running the check, but also configuration items like retry strategies (for scheduled checks.) In addition, the parent class ProblemCheck also serves as a registry for checks. For example we can get a list of all existing check classes through ProblemCheck.checks, or just the ones running on a schedule through ProblemCheck.scheduled. After this refactor, the task of adding a new check is significantly simplified. You add a class that inherits ProblemCheck, you implement it, add a test, and you're good to go.
38 lines
949 B
Ruby
38 lines
949 B
Ruby
# frozen_string_literal: true
|
|
|
|
RSpec.describe Jobs::ProblemChecks do
|
|
before do
|
|
::ProblemCheck::ScheduledCheck =
|
|
Class.new(ProblemCheck) do
|
|
self.perform_every = 30.minutes
|
|
|
|
def call = []
|
|
end
|
|
|
|
::ProblemCheck::NonScheduledCheck = Class.new(ProblemCheck) { def call = [] }
|
|
end
|
|
|
|
after do
|
|
Discourse.redis.flushdb
|
|
AdminDashboardData.reset_problem_checks
|
|
|
|
ProblemCheck.send(:remove_const, "ScheduledCheck")
|
|
ProblemCheck.send(:remove_const, "NonScheduledCheck")
|
|
end
|
|
|
|
it "schedules the individual scheduled checks" do
|
|
expect_enqueued_with(job: :problem_check, args: { check_identifier: "scheduled_check" }) do
|
|
described_class.new.execute([])
|
|
end
|
|
end
|
|
|
|
it "does not schedule non-scheduled checks" do
|
|
expect_not_enqueued_with(
|
|
job: :problem_check,
|
|
args: {
|
|
check_identifier: "non_scheduled_check",
|
|
},
|
|
) { described_class.new.execute([]) }
|
|
end
|
|
end
|