On Thu, Oct 30, 2014 at 6:47 PM, Ulli Hafner <[email protected]> wrote: > Maybe we should move such integration tests to the acceptance test harness > project.
These are not integration tests and do not belong in acceptance-test-harness. I do notice that JellyTestSuiteBuilder runs with a live Jenkins instance (inside a request handling thread). This is probably unnecessary; I suspect it could be modified to run as a unit test, essentially instantaneous. CliSanityTest also runs with a live Jenkins instance but I wonder if that could be optimized, for example by first checking if there are any CLICommand’s or CLIMethod’s registered in the plugin, and quickly returning if not. Disabling JellyTestSuiteBuilder would be dangerous as one thing it checks is that you are consistently using <?jelly escape-by-default='true'?> without which your plugin is highly vulnerable to XSS bugs. Although perhaps at this point we can switch the default in Stapler Jelly to assume escaping? (On the rare occasions where you do trust the source and want to emit unescaped HTML, you should make this explicit with <j:out>.) -- 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]. For more options, visit https://groups.google.com/d/optout.
