Hey kzantow Could you take a look at this?

I think it should suffice to make the System property check into a tri-state true/false/null, with the latter being the default behavior (show if necessary), the first two forcing to (not) show the install wizard. WDYT?

rtyler Could you clarify whether this is for the install wizard (pristine Jenkins home) only, or whether you also need this for the upgrade wizard banner feature that shows when Jenkins detects it was upgraded from 1.x to 2.x?

R. Tyler Croy Could you clarify whether this is for the install wizard (pristine Jenkins home) only, or whether you also need this for the upgrade wizard banner feature that shows when Jenkins detects it was upgraded from 1.x to 2.x?

If I am provisioning with good automation, I believe any form of wizard should be suppressed. I view the 'Getting Started' wizard and the Upgrade Wizard conceptually to be two facets of the same feature I would want to disable in a Puppet automated environment.

rtyler danielbeck I've implemented a something to handle, but note a reservation here that 'automated deployments' which may be scripted to bypass the setup wizard and bypass the initial setup will also bypass security setup currently, which seems to be a potential issue. I would strongly advise against making any distribution disable this, rather only use it for your own automated deployments where you're providing a configuration that includes whatever security configuration you would like, otherwise we're in the same boat with a bunch of unsecured Jenkins instances popping up all over the place again.

kzantow I understand the concern, but if a user is automating their Jenkins installation and doesn't set up security, forcing the Getting Started Wizard I do not believe is productive (I would also consider those users "advanced").

There's nothing we can do well right now as far as encouraging secure defaults with Puppet/Chef/etc until something like JENKINS-31094 is introduced. There's been discussion in the puppet-jenkins repo (the issue/pull request eludes me right now) about how difficult it is to stand up a secure Jenkins installation in a deterministic and idempotent manner. IMO this is out of scope for this request though

rtyler oddly enough, you could just read the security token and make 2 requests (1: post the auth info, 2: hit the 'complete install' with a cookie from step 1) and these jenkins instances would be 'secure'. if you're going to the trouble to automate deployments, you should have programmatic access to the jenkins home as well as a URL to access the Jenkins system. as long as this was documented (I can do that), i assume advanced users could figure out how to do those basic tasks. yes, it's a few extra steps, but if you're scripting anything meaningful that seems likely to be a drop in the bucket.

rtyler anyway, I'm not exactly opinionated either way, just pointing out that this undermines one of the things Jenkins 2 is supposed to be improving. I really don't like the security token / generated admin from a user experience standpoint, but I see it as a necessary evil for the time being, given what danielbeck is trying to accomplish and I'm not sure having an easy way to automate completely bypassing it is the right thing to do.