-
Bug
-
Resolution: Fixed
-
Blocker
According to danielbeck in this thread
You could alternatively just go with patching the JENKINS_HOME so Jenkins considers it not an update:
$ echo -n 2.0 > $JENKINS_HOME/upgraded
$ echo -n 2.0 > $JENKINS_HOME/.last_exec_versionThe files are being renamed in https://github.com/jenkinsci/jenkins/pull/2215, but for beta 2, the above appears to work.
But please note that this is considered internal storage so may not work this way forever. I think we'll pretty quickly introduce a supported alternative way though.
Based on comments by kzantow earlier in the 2.0 development cycle, I was under the impression that setting the system property jenkins.install.runSetupWizard=false would suffice.
Apparently this is not true.
For me, and my co-maintainer of the puppet-jenkins module jhoblitt, I believe the lack of a consistent and supported way to disable the "Getting Started" wizard is a blocker for 2.0. We cannot build reliable automation around provisioning Jenkins 2.0 (Puppet, Chef, etc) without it.
- links to
[JENKINS-34035] 2.0 needs a stable/supported way to disable the Getting Started wizard
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.
Joshua Hoblitt
added a comment - - edited 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. Joshua Hoblitt
added a comment - 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
Joshua Hoblitt
added a comment - 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?
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
jhoblitt for said deployments, are you providing a config.xml? If the version is set properly, that should bypass the setup wizard already (ok, there's probably an issue with the upgrade wizard here). It seems like more work to deal with deployment flags. Is dealing with the config.xml part of the problem?