Job-level event location overrides?

Deadline
1

For some reason I have this idea that it should be possible to specify a custom event directory (override?) for a given job, similar to what can be done for plugins. However, I can’t find any information on how to do this, or any obvious bread-crumbs in the Monitor. Is this possible, or am I crazy?

Thanks.

2

Hello Nathan,

As far as I am told events scripts must be in /events or /custom/events/ as Deadline doesn’t have code to look anywhere else for them.

3

You can load an app plugin from a custom defined directory path, but as Dwight said, it’s not possible for event callbacks:
docs.thinkboxsoftware.com/produc … nvironment

Maybe you were thinking of this and not going completely crazy on us :slight_smile:

4

Thanks guys. I definitely know about the plugin location override, as we use it for every job we run, but I couldn’t remember if there was parallel functionality for event plugins. Feature request perhaps?

5

Hi Nathan,
Can I ask is the need to specify a custom event plugin directory due to performance/caching reasons? Quite a few changes will be taking place in the area of ‘events’ in v8.0 and I just want to understand the reasoning behind the request.

6

No, it’s not for performance reasons. I’m interested in being able to run development or otherwise split versions of event plugins in the same way we can for our custom job plugins. Right now, there is no way to safely dev an event plugin.

7

In v8 we don’t have per-job event directory overrides, but we do have per-job event opt-ins.

Events plugins will be able to be marked as Global, Opt-In, or Disabled. Global behaves as event plugins currently do in 7, they get invoked for each job. The Opt-In ones only trigger for Jobs that have opted into that particular Event.

This obviously doesn’t really handle the case of having separate versions of the same plugin, though, so I’ll add it to the request pile. We could probably get to it for 8.

Cheers,
Jon

8

Hmmm, actually, I just realized this might conflict with how we’re caching Event Plugins now.

I’ll have to give it some more thought, but this might be slightly more involved than I first thought… Either way, it’s officially on the request pile now :slight_smile:

9

Thanks for the info Jon. Having an opt-in system would make the dev situation slightly easier, but obviously wouldn’t quite bring it into parity with the job plugin system. I wouldn’t consider this a high-priority request though… development just has to be done in very careful steps.

10

I usually just have one machine with its own Repo and DB on it so I can commandeer it for dev work. An idle DB usually only takes about 45MB of RAM.

11

Yeah, unfortunately that option is more than a little unwieldy in my case due to the amount of custom code we have running to submit, track, run, and clean up the Deadline jobs.

12

I don’t know how useful this is in your case. But I usually test event scripts by tying it up to only trigger on jobs that are sent with my username and have a test production code (in extra info).

13

Ya gotta treat it like web development. Have a staging area for hacking on, and production. Here we kind of have a tree thing going on:

\\deadline\production
    \\deadline\dev7
        \\workstation-01\dev
        \\workstation-02\dev
        \\workstation-03\dev

Production usually lags behind dev7 here because it’s used by people to build Draft, Deadline, Frost, etc. The nice thing is that with automatic upgrades the Slaves can be pretty fluid, but I’m not sure how your pipelines have been set up. There may be more interplay between things than I expect.

Whatever works though right?