Hey,
Is it possible to point Deadline to external custom folders with plugins and event plugins?
External Custom app plugin can be loaded via Environment in Job Props and declared at submission time or otherwise:
docs.thinkboxsoftware.com/produc … nvironment
Event Plugins could be re-directed via Python sys.path but you would need to make sure that all parts of Deadline that might be the application which triggers and executes the event plugin, actually have routable access to where you store the custom event plugin(s).
It’s also worth noting that storing them externally, would mean you wouldn’t take advantage of the new caching system for all plugins, events, scripts, 3rd party api’s etc recently introduced in 8.0.
So generally its against the Deadline workflow to do so?
It would be nice to able to point to external plugins and event plugins, so you can link to git repos etc.
So generally its against the Deadline workflow to do so?
No. You are more than welcome to fork into the “/custom” directory or redirect to another external path for plugins/events.
It would be nice to able to point to external plugins and event plugins, so you can link to git repos etc.
Yes, that’s fine.
You could probably symlink the plugins and events directories as well. Although can’t say I have tested that in recent years. I’ll ask around to see if anyone has played with that approach.
Thanks Mike, would be great to hear how other people are handling this:)
I have a couple of events symlinked from a git repo and they seem to work fine. I do make an effort to manually run ‘Synchronize Scripts and Plugins’ whenever I do a pull on the repo, to ensure everything plays nice.
However I’m not running a farm or very many jobs. There could be use issues I haven’t hit.
Hi,
We use “/custom” , but not directly.
All code that lives below this point is stored in git and we try as hard as possible to not edit files here directly and have a release script that checks out tested code to the the tree below.
The smallest syntax error, causes lots of fails . 
As suggested by Justin and Edwin, we have a few spare deadline servers we use to test bigger changes against real jobs and nodes, before checking them out to the main farm.
For our workflow for plugins, we use “/custom/plugins”, we start with the default plugin name, Nuke, rename it to GuruNuke.
Make all our pipeline specific changes, and make jobs use these plugins instead.
This helps allot, because when we do minor updates, we can diff the new code changes of the original plugin vs our one, test the changes and release.
Hope this is helpful.
Thanks kwatts:)
I’ve been using a similar approach with “\custom” being a git repo, though this doesn’t work out too well if you want to shared individual plugins.