Why?
I just thought it would be fun to try this experiment: decorate (wrap) dynamically any Rake task execution with some arbitrary code.
Also, it would be nice if I could do it even for tasks defined outside my project, for example in gems, without having to modify the source-code.
Examples:
- Custom logging around task's execution (e.g. time spent, maybe using funny colors)
- Run a Rails DB task in read-only mode (setting ActiveRecord connection to use a replica DB)
- Notify in Slack the results of some tasks
- ...etc., you name it
I'm not going to use Rake::Task.enhance which, as you may already know, allows you to execute another Rake task as a dependency before and/or after the "enhanced" task, because you lose some context, and in order to do things like referencing a variable defined at the "before"-task from the "after"-task, you may need to resort to some trickery...
How?
Recently, I've learned about Rule Tasks. As per the documentation, "rules" let you
synthesize a task by looking at a list of rules supplied in the Rakefile.
This feature can be (ab)used to accomplish my goal... The rule-block receives (as arguments) an instance of Rake::FileTask (which responds to #name) and the arguments passed to the task; we could do something along the lines of:
rule /^decorated:.*/ do |t, args| task_name = t.name.delete_prefix('decorated:') # Code to be executed BEFORE the task... Rake::Task[task_name]).invoke(*args) # Code to be executed AFTER the task... end ~~~{% endraw %} In the previous snipppet, invoking Rake with a task name prefixed by a "marker" string, will be processed by this rule. (I chose {% raw %}`decorated:`{% endraw %} but actually it could be anything, I just felt that using {% raw %}`<label>:`{% endraw %} looked more Rake-ish 😉) Despite it seems "rules" where designed to be used with file-name matching patterns in mind (like you do with GNU Make), it does the trick anyway; yeah, hacky, I know. This is an example that logs task's execution time:{% raw %} ~~~ruby rule /^timed:.+/ do |t, args| task_name = t.name.delete_prefix('timed:') start_time = Process.clock_gettime(Process::CLOCK_MONOTONIC) Rake::Task[task_name].invoke(*args) end_time = Process.clock_gettime(Process::CLOCK_MONOTONIC) total_time = end_time - start_time Rails.logger.info("#{task_name} executed in #{total_time} seconds") end ~~~ Then, you can simply do, for example: ~~~shell bundle exec rake timed:db:seed ~~~ And, yes, the meticulous reader may have noticed that it doesn't return the "total" time as when using the shell's `time` command (as in `time bundle exec rake ...`), since it doesn't take into account any startup related overhead, but the example was just for illustration purposes. Now, this code has a problem though... if the invoked task fails (which usually means it executes {% raw %}`exit`{% endraw %} or {% raw %}`abort`{% endraw %}, and thus a {% raw %}`SystemException`{% endraw %} is raised), the next line of code after {% raw %}`Rake::Task[task_name].invoke`{% endraw %} won't be executed. Well... not the cleanest way in the world, but we can leverage [`at_exit`](https://ruby-doc.org/core-2.7.2/Kernel.html#method-i-at_exit) to register a block so that it's always executed at program's exit no matter what: ~~~ruby rule /^timed:.+/ do |t, args| task_name = t.name.delete_prefix('timed:') start_time = Process.clock_gettime(Process::CLOCK_MONOTONIC) at_exit do # Here goes the "after-task" code total_time = end_time - start_time Rails.logger.info("#{task_name} executed in #{total_time} seconds") end Rake::Task[task_name].invoke(*args) end ~~~ Neat 🙂 Note that you can also compose these "decorator rules": ~~~shell bundle exec rails safe:timed:db:drop ~~~ where `safe` could be the following rule: ~~~ruby rule /^safe:/ do |t, args| task_name = t.name.delete_prefix('safe:') print "Do you really want to perform this action (yes/no)? " confirmed = gets.chomp == 'yes' if confirmed Rake::Task[task_name].invoke(*args) else puts "Phew... almost did some crazy thing" end end ~~~ And that's all. ## Closing words In the "real world", the use of this technique may be arguable and even frown-upon, because there's too much magic going on (read it "brittle non-explicit stuff"), but hey... it may help you debugging an issue (like it did for me) or with some ad-hoc code that you won't commit into that pristine application code-repository 😬 ---- *Cover image: ["Max and Ruby Party"]( https://www.flickr.com/photos/13698839@N00/3221858084) by Kid's Birthday Parties is licensed with CC BY-ND 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nd/2.0/* 
Top comments (0)