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.

Speaking for myself, I deploy test instances of jenkins via puppet, with security configuration, several times a day. I neither need nor want "clippy" popping up at me nor do I want to be forced into screen scraping to perform an unattended deployment. Working well with Configuration Management is an absolutely critical component to a DevOps user narrative. Jenkins already does this poorly and making clippy mandatory only makes the situation worse.

jhoblitt There's already a pull request for this and this is being considered as a late addition for 2.0 RC, scheduled for release later today. Given that, could you please clarify what your comment's purpose is?

danielbeck That I am in favor of said PR, which is not as of this moment merged.

jhoblitt Code reviews are not done yet. Still, I expect we'll merge it in time for 2.0 RC.

kzantow neither puppet-jenkins or chef-cookbooks/jenkins attempt to mange config.xml directly. The main config potentially interacts with so many plugins that it becomes an all or nothing affair unless one wants to attempt to semantically understand the xstream serialization. And don't forget that plugins may also have independent config files (with somewhat difficult to predict names). I concede that it is possible to manage jenkins by copying all of the xstream dumps around as opaque blobs but this doesn't allow you to express any meaningful configuration via a CM tool. The same result could be achieved by copying around a tarball.

Most of the CM integration I've looked at use some combination of the pre-canned CLI commands along with groovy scripts feed in via the CLI. I believe this has been the general preference over the REST API as an ssh public key may be user defined. However, I will confess to doing awful things in puppet-jenkins in order to be able to set the API key for a user account to a known value. While the gymnastics the CM integration maintainers are doing is working to a degree, it is painful and requires considerable effort for every new feature.

kzantow If a concrete example would be helpful, this is what a jenkins deployment (partially driven by hiera data) using some of the experimental functionality in puppet-jenkins looks like: https://github.com/lsst-sqre/sandbox-jenkins-demo/blob/master/jenkins_demo/manifests/profile/master.pp#L5-L187

Code changed in jenkins
User: kzantow
Path:
core/src/main/java/jenkins/install/InstallUtil.java
core/src/main/java/jenkins/install/SetupWizard.java
core/src/main/java/jenkins/install/UpgradeWizard.java
http://jenkins-ci.org/commit/jenkins/82c9e03d5ca9d3ad237c11842fb83d9467bae6d3
Log:
JENKINS-34035 - honor jenkins.install.runSetupWizard=false

Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/jenkins/install/InstallUtil.java
core/src/main/java/jenkins/install/SetupWizard.java
core/src/main/java/jenkins/install/UpgradeWizard.java
http://jenkins-ci.org/commit/jenkins/52cc5f858108674ee70f76dbff0151eac864fadd
Log:
Merge pull request #2223 from kzantow/JENKINS-34035-easy-skip-setup-wizard

[FIXED JENKINS-34035] - honor jenkins.install.runSetupWizard=false

Compare: https://github.com/jenkinsci/jenkins/compare/c403e88f4403...52cc5f858108

It seems that this was included in the 2.27 release even thou it's not mentioned in the Changelog

FTR, this change is part of Jenkins 2.0 and not mentioned anywhere since the feature was added during the 2.0 preview/beta releases and this issue discovered and fixed before 2.0.

Hi, when I disable the Getting Started Wizard, the "slave to master connection" was disabled by default.

Could you tell me how can I disable the setup wizard without disable slave to master connection?

This is not a support site.

For possible reference, please note that if you're looking for a definitive and up to date list of available system properties, you want to look at https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties