On Tue, Oct 13, 2015 at 1:06 PM, Kanstantsin Shautsou <[email protected]> wrote: > better create db-plugin with some hibernate and provide API
KK actually already did this part—and then stopped there. :-) > start migrating plugins / unbundling existed core API to use this db-plugin Yes, that would be the approach I suggest too. The open question is how much work it is to maintain incremental settings compatibility when updating plugins to versions that expect the DB. Also it is one thing to migrate a plugin like `junit` which has a `testResults.xml` that it writes and it reads. But we need to handle the general `build.xml`, which is extensible with `Action`s that are expected to be XStream-serialized. So there needs to be a way to keep `Action`s from unmigrated plugins in XML format somewhere, while allowing migrated plugins to keep their data in a DB, and doing all this transparently to other code that just expects a `Run` to be `Actionable`. Will require some planning to get this right. Settings (`config.xml`) are then another matter, though I think this is a lower priority than build records. The main use case for keeping these in a (cloud) DB is to implement transparent load balancing, but that brings up other issues with in-memory global state (for example in the `Queue` but certainly not limited to that). -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1xixTAv8bg5VPyx9Jt6pXKNSypUm%3DYyGkaJegq2q%3Drzg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
