Hi everyone, This is a pre-JEP email per https://github.com/jenkinsci/jep/tree/master/jep/1#discuss-the-idea-with-the-community
Please provide feedback whether this looks worthwhile/feasible, and what questions you'd like to see answered in the JEP. Thanks! Daniel --- We are occasionally in the situation that we need to understand how Jenkins is used or configured, typically to estimate the feasibility or impact of a planned change. As Jenkins is not a hosted SaaS, but distributed for local installation, we have very limited ways to get any information from our users in advance of actually performing the changes. Combined with the complexity of having 1500+ plugins with virtually unrestricted access to internal APIs means the risk of problems due to major changes is rather high. While we have _some_ tooling (mostly related to Java API use across components), that might only be a small subset of what we'd need to know. While there are anonymous usage statistics, the data provided is fairly limited (mostly basic master/agent setup, job types and count, and installed plugins), and the collection protocol does not allow for it to be easily extended with additional information. Not to mention that the server-side processing is a mess and very difficult to change. Therefore I propose a second, independent usage telemetry collection system with the following properties: * Handles specific information needs: While the proposed basic collection service (both client and server) is generic, the specific information would be collected using extension implementations that are tailored to a specific information need. * Defined, limited collection time span: Data for a specific purpose is only collected during a specific time frame determined in advance. * Admin controlled: Data is collected if and only if the instance allows anonymous usage statistics collection. * Restricted data access: Only select board members and officers of the Jenkins project have access to the raw collected data and will make that data available in an aggregate form to specific, previously determined developers. This will keep both the client side and server side simple -- we’re not plotting monthly updated graphs of install stats, but rather collect information for a few weeks, evaluate it (perhaps just by grepping a bunch of files), and it’s over. What follows below is an _example_ for a specific information need to illustrate a potential use case. It's not what the JEP would be about -- the JEP would define the generic infrastructure (extension point, collection service, etc., not a specific information collector. Information collected is also not necessarily related to System properties, but can, in principle, gather any information. We'd also never want to collect actual user data like job or user names, but just anonymous information about configuration and usage. ---- Example use case: The Jenkins security team routinely adds 'escape hatches' to security fixes, typically in the form of system property flags that can disable a fix. We don’t know whether they’re actually needed, or how commonly they’re used. While we consider system properties unsupported (i.e. they can, in theory, be removed at any time), to the best of my knowledge we’ve never done so unless they simply didn’t apply anymore. So I'd like to collect the values of several system properties for a duration of 4 weeks: * hudson.ConsoleNote.INSECURE (as boolean) * hudson.model.ParametersAction.keepUndefinedParameters (as boolean) * hudson.model.User.allowNonExistentUserToLogin (as boolean) * hudson.model.User.allowUserCreationViaUrl (as boolean) * hudson.model.User.SECURITY_243_FULL_DEFENSE (as boolean) * Whether hudson.model.ParametersAction.safeParameters is set to a non-empty string. * Whether hudson.model.DirectoryBrowserSupport.CSP is defined, and if so, whether it's an empty string. Additional metadata to be collected to provide context for some of the above: * Jenkins core version * Number of user records on disk * Class name of the configured security realm -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4771DB01-87A8-456C-BC67-765984BBC4BA%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
