Jobs loaded and executed from XML rather than loaded from XML and executed from DB

i suppose something like this could be set up with jenkins/hudson; the job.xml are in source control and when updated a jenkins job is executed that imports them into rundeck.

i.e. normal source control workflow could be used, rather than baking it into the RunDeck system. this is just an observation. We have also talked about ways to organize the job xml on disk as the authoritative source and sync changes made via GUI (like jenkins/hudson does for jobs)

As a convention, I've been placing them in /var/rundeck/projects/<project>/jobs.d and then rd-jobs load'ing them from there.

+1 on @John's point. Possible next steps:

1) decide sync model/life-cycle for job defs between file system and DB
2) discuss configuration settings specifying where job defs live on the FS
3) reconcile changes made through the gui to (versioned?) files on the FS

I'd definitely like the ability to tell RunDeck where my git-managed directory is located, such that any change to any manually altered RunDeck element would be kept there: jobs, resources, jaas policies, etc.

Data generated from RunDeck actions should NOT go there.

Yes, making it a point for plugins would definitely be a requirement of this. I think the crucial questions for this issue are:

• how/when should job definitions be "synched" between the RD datastore and any plugins that provide the definitions?
• Should it be two way, such that any change to a job definition gets written back through the plugins? Or should each plugin get to decide whether it can do this?
• How can a plugin tell Rundeck that something has changed? i.e. push a new definition into Rundeck? (this can already be done with the API)

Some of this overlaps with the existing API: you can already read and write jobs to Rundeck that way.

If we consider the issue in light of a Webhook model, then other web services could perhaps 'subscribe' to job definition data and receive changes via HTTP.