From 1b4af5bde12917111a9d1891a57d5f0f7d94ddd1 Mon Sep 17 00:00:00 2001 From: Marek Hulan Date: Tue, 1 Dec 2020 11:01:49 +0100 Subject: [PATCH] Fixes #30670 - start dynflow client in report tasks As reported, a single foreman-rake reports:daily in fact triggers the rake task twice. This is caused by plugins that need to extend this (and similar tasks) with their own logic and add other rake tasks dependencies. For that they need to `load` our core tasks, causing the duplication. `load` should be avoided entirely. In this specific case though, the need was to add dynflow:client dependecy to reports, since Katello plugin may schedule some dynflow job as part of that. Therefore it needs client connection to dynflow. This task does not start the executor. Instead of asking all plugins to add such dependency if their custom mail notification requires dynflow client, the Foreman core should offer this by default. The real fix needs to land in Katello, it should no longer load the core task definition, however in order for that to be possible, this PR needs to be merged first. What was tried: * modify the Katello in a way requiring the task does not cause duplicity * clearing the task after it's loaded - this helps but may have other consequences and does not solve the issue for other plugins --- lib/tasks/reports.rake | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/tasks/reports.rake b/lib/tasks/reports.rake index a5ff29a69b1..ef077138328 100644 --- a/lib/tasks/reports.rake +++ b/lib/tasks/reports.rake @@ -108,15 +108,15 @@ namespace :reports do end end - task :daily => :environment do + task :daily => [:environment, 'dynflow:client'] do process_notifications :daily end - task :weekly => :environment do + task :weekly => [:environment, :'dynflow:client'] do process_notifications :weekly end - task :monthly => :environment do + task :monthly => [:environment, :'dynflow:client'] do process_notifications :monthly end end