In BBB 2.5, we switched the recording system to use bundled gems
included privately in the recording package, rather than installed
system-wide. The rap-enqueue.rb script needs to be updated to load the
bundler gems.
According to bundler devs, setting the BUNDLE_GEMFILE environement
variable is the supported way to tell bundler where to find it
(otherwise bundler will search starting at the current working directory
- which in the case of rap-enqueue.rb is probably nowhere near the
Gemfile).
Use a relative path from the directory where the script is located so it
can be run both when installed and from a development environment.
Switch the script interpreter to use /usr/bin/env to load ruby from the
path. Doesn't make a difference in the installed package, but it makes
testing on development systems with multiple ruby environments easier.
Fixes#15085
Previously, bbb-record --rebuild was restarting recording processing
from scratch by creating the .../recording/<meeting_id>.done file. This
causes the recording to be reprocessed starting at the archive step.
However, re-running the archive step for an existing meeting is not
really supported! Ever since the segmented recording code was added, it
shouldn't /corrupt/ the recording files, but it's still not good.
And as a side-effect, re-running the archive step will re-create the
.norecord file for meetings without recording marks, meaning that you
cannot use bbb-record --rebuild to force a recording without marks to be
processed.
Switch bbb-record to restart recording processing at the sanity stage to
match the BBB 2.2 behaviour. Rather than have it insert tasks directly
into resque via redis-cli, it goes through a ruby wrapper that performs
input validation and uses the resque apis.
