Hello! This PR adds the job class capability to rq-dashboard. Please let me know what additional sort of unit tests you'd expect to see; I've formatted with isort and black and ensured pytest and flake8 are passing.
For my company's internal implementation of RQ we use a custom job class as described here:
The way the RQ API works, you essentially need to pass this every time you construct an object (there's no global variable for this).
Also, not every function in RQ is capable of respecting this setting. In particular, rq-dashboard uses requeue_job which is incapable of respecting the setting so I replaced it's usage.
This PR would add the capability to specify this according to what I perceive to be the pattern in the repo. Internally, RQ accepts this parameter as a string - rq-dashboard would too, if this is accepted, which I think is the simplest way to specify it for the operator.
Description
Hello! This PR adds the job class capability to
rq-dashboard
. Please let me know what additional sort of unit tests you'd expect to see; I've formatted with isort and black and ensured pytest and flake8 are passing.For my company's internal implementation of RQ we use a custom job class as described here:
https://python-rq.org/docs/workers/#worker-arguments
The way the RQ API works, you essentially need to pass this every time you construct an object (there's no global variable for this).
Also, not every function in RQ is capable of respecting this setting. In particular, rq-dashboard uses
requeue_job
which is incapable of respecting the setting so I replaced it's usage.This PR would add the capability to specify this according to what I perceive to be the pattern in the repo. Internally, RQ accepts this parameter as a string -
rq-dashboard
would too, if this is accepted, which I think is the simplest way to specify it for the operator.