Resque encourages plugin development. For a list of available plugins, please see http://wiki.github.com/defunkt/resque/plugins.
The docs/HOOKS.md
file included with Resque documents the available
hooks you can use to add or change Resque functionality. This document
describes best practice for plugins themselves.
Plugins should declare the major.minor version of Resque they are known to work with explicitly in their README.
For example, if your plugin depends on features in Resque 2.1, please list "Depends on Resque 2.1" very prominently near the beginning of your README.
Because Resque uses Semantic Versioning, you can safely make the following assumptions:
- Your plugin will work with 2.2, 2.3, etc - no methods will be removed or changed, only added.
- Your plugin might not work with 3.0+, as APIs may change or be removed.
All plugins should live under the Resque::Plugins
module to avoid
clashing with first class Resque constants or other Ruby libraries.
Good:
- Resque::Plugins::Lock
- Resque::Plugins::FastRetry
Bad:
- Resque::Lock
- ResqueQueue
Gem names should be in the format of resque-FEATURE
, where FEATURE
succinctly describes the feature your plugin adds to Resque.
Good:
- resque-status
- resque-scheduler
Bad:
- multi-queue
- defunkt-resque-lock
Job hook names should be namespaced to work properly.
Good:
- before_perform_lock
- around_perform_check_status
Bad:
- before_perform
- on_failure
Plugins should test compliance to this document using the
Resque::Plugin.lint
method.
For example:
assert_nothing_raised do
Resque::Plugin.lint(Resque::Plugins::Lock)
end