I don't know anything about slurm, but assuming that needs to spin up a remote node to the do the job it is probably still possible, but I'm not sure it's a good fit because I don't know about slurm yet :)
What happens right now is the scm plugin runs to checkout the code on the worker, the checkout happens, then the isolation plugin runs the actual build.
If you wanted to simply copy those files to a remote note and then run the build on those new nodes and copy the results back, yes, that would technically work.
However, it sounds more like you might just want to keep some workers running on your cluster.
Another idea that has come up is the idea of having plugins that autoscale themselves based on the number of builds in queue for a given worker pool. If we were to do this we would probably have a new type of plugin ("autoscaling") of which you could configure AWS or OpenStack or whatever to scale up or down a worker pool automatically based on the number of queued jobs.
This could also take some parameters as to the minimum and maximum size.
In that configuration we could (optionally) also teach the worker a new flag where the worker just ones one job and then immediately exits or have some way for it to ask the overseeing worker whether it should spin down or not.
This type of autoscaling plugin does not currently exist. If that's more of what you are looking for I'd be willing to write a stub for it, even a basic one that just executes shell commands might be a start.
Technically you could use the isolation plugin infrastructure now but you'd still need a worker to do the checkouts and ship them off, and those workers would be idle until the job returned.
That might be ok, say if you have crazy long job times - you'd just have one vespene worker waiting on that slurm job to complete using the isolation plugin you wrote, until it came back.
As I'm not sure if you want more of that case or the other, let me know and we can see what we can do.
As slurm isn't all that common, it probably wouldn't be something I'd want to maintain in tree, but it's also something I think the plugin ecosystem could easily accomodate.