Daniel Beck, as I commented on the related closed jenkins issue <https://issues.jenkins.io/browse/JENKINS-57484?focusedCommentId=410835&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-410835>, I can't understand the usefulness of this feature for automated installs, which inherently will be setting `jenkins.install.runSetupWizard = false`. Can you help me understand the use case for this PR <https://github.com/jenkinsci/jenkins/pull/4027>?
I'm trying to achieve essentially the same thing (want to pre-seed an api token to enable api access during initial jenkins provisioning), and months ago came to learn (via gitter) of the new Djenkins.install.SetupWizard.adminInitialApiToken option. I'm on 2.289.1 and Djenkins.install.SetupWizard.adminInitialApiToken=<my-pre-determined-34-char-token> simply has never worked for me. The docs for this option <https://www.jenkins.io/doc/book/managing/system-properties/#jenkins-install-setupwizard-admininitialapitoken> indicate that it: > determines the behavior during the SetupWizard install phase concerning the API Token creation for the initial admin account. So, it would seem for automated installs like ours which must disable the setup wizard, this option is innefectual, by design. No? On Gitter, Tim Jacomb <https://issues.jenkins.io/secure/ViewProfile.jspa?name=timja> pointed me to the PR that introduced this feature <https://github.com/jenkinsci/jenkins/pull/4027> by Wadeck Follonier <https://issues.jenkins.io/secure/ViewProfile.jspa?name=wfollonier>, whose description seems to indicate this is by design: > No impact once an instance is configured. Any advice? I tried it with and without running the setupwizard, and I've never been able to use the token to authenticate as my admin user in a new Jenkins instance. So far, the big items I want to use the API for during provisioning are mostly putting jenkins into quietDown mode and safeRestarting - the former only useful during subsequent ansible provisioning, and the latter, which can also be done by simply restarting jenkins service, is required to absorb the build history which we're copying over from the production jenkins controller during provisioning. More importantly, having a pre-baked API token would be highly useful for implementing test automation in the provisioning (ansible) playbooks. Using CasC to automate configuration is great, but insufficient in the same way that adding a new feature to any software project is insufficient until there are automated tests that can validate the new behavior. Should I just give up on the Djenkins.install.SetupWizard.adminInitialApiToken approach and roll my own automation using the old-school crumb (CSRF token) approach? On Tuesday, December 8, 2020 at 12:54:30 PM UTC-8 Daniel Beck wrote: > > > > On 1. Dec 2020, at 11:40, Shahbaz Subedar <[email protected]> wrote: > > > > -Djenkins.install.runSetupWizard="false" > > > -Djenkins.install.SetupWizard.ADMIN_INITIAL_API_TOKEN=11b9b3fafe25923768621ca1b64d44bfd1 > > > > You're disabling the setup wizard, and then set an option that is > > > only used before/during the Setup Wizard > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/826e663d-c2b3-4178-afb4-1d14ad4dc5b0n%40googlegroups.com.
