• Icon: Epic Epic
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • 2.0: Out of the box experience

      Problem Description

      When a new user installs Jenkins, they are greeted with the main, empty, dashboard which suggests that they "create jobs." This makes no mention of plugins or the configuration options that are relevant to helping the user make Jenkins match their needs.

      Proposal

      Instead of changing the post-install defaults, which may not properly represent the user's needs, the first-time user experience should help guide the user through configuration and plugin installation quickly so they can use Jenkins for their needs. Effectively it should be as easy as possible for a user to arrive at a good configuration for their usage.

      Part of this would entail:

      • Changing how plugin bundling works, no automatically installing plugins just for backward compatibility
      • Encouraging use of pipeline-as-code enhancements discussed previously

      Impact

      This would primarily change the way in which first-time users would use Jenkins.

      Open Questions

          [JENKINS-31157] 2.0: Out of the box experience

          Michael Litwak added a comment - - edited

          I suggest developing a "configuration wizard" in the initial UI which would prompt the user with a series of questions to gather details on how they intend to use Jenkins. For example:

          1. Do you intend to use Jenkins to build software? (other possibilities include running arbitrary scheduled jobs).
          2. On which platforms do you build (multi-select list, e.g. Windows, Mac, Linux, etc.)?
          3. Which of the following source code repositories do you or your team use (multi-select list, e.g. git, Subversion, Perforce, Mercurial, etc.)?
          4. Which of the following build systems do your projects utilize (multi-select list, e.g. Ant, Maven, Gradle, SBT, Visual Studio, MSBuild, Bazel, etc.)?
          5. For each application you build, specify the NAME of the application, the PLATFORM (multi-select list, e.g. Windows, Mac, linux, etc.) which it is built on, the source control program name which holds this application's source code, the FULL PATH to the build script to build that application, and a default list of people who should be emailed if builds for this application fail.
          6. For each build machine (Jenkins slave and/or master), specify the computer NAME or HOST IP and the PLATFORM (multi-select list, e.g. Windows, Mac, Linux, etc.), as well as the source control program name(s) (from a list) which are available on this machine, and the corresponding working copy folder path(s).
          7. Do you utilize any container systems (multi-select list, e.g. Docker, Rocket, Drawbridge, Spoon, LXD, etc.)?
          8. Do you utilize VM's for post-build installation & testing (multi-select list, e.g. VMware, Hyper-V, AWS EC2, Azure, etc.)?

          The above question list could be expanded and turned into a 'tree", where certain responses lead to different follow-up questions. In the end, the program would have enough details to implement an initial Jenkins configuration, including plug-ins.

          A second "job wizard" – or the regular job configuration screen – could then prompt the user to establish a job, e.g.

          1. Specify whether this new job will br created "from scratch", or whether it will be based on the settings of an existing job (if any exist).
          2. Specify a description for this job.
          3. Select the application name and build script (as specified in the first Wizard) for this job
          4. Specify any additional command-line parameters for the build script for this job.
          5. Select one or more build machine(s) (as specified in the first Wizard) which will build this application.
          6. Specify the build frequency / triggers for this job.
          7. Specify the path to the primary build log file produced by this build, and whether this log should be attached to any "build failed" email notifications.
          8. Specify the path to any unit test output files produced by this build which are in JUnit XML Format.
          9. Specify the path to any code coverage output files that a Jenkins plug-in should analyze.
          10. Specify email notification options (optionally override defaults setup in the first wizard)
          11. Specify any other pre-build or post-build actions.
          12. etc.

          Michael Litwak added a comment - - edited I suggest developing a "configuration wizard" in the initial UI which would prompt the user with a series of questions to gather details on how they intend to use Jenkins. For example: Do you intend to use Jenkins to build software? (other possibilities include running arbitrary scheduled jobs). On which platforms do you build (multi-select list, e.g. Windows, Mac, Linux, etc.)? Which of the following source code repositories do you or your team use (multi-select list, e.g. git, Subversion, Perforce, Mercurial, etc.)? Which of the following build systems do your projects utilize (multi-select list, e.g. Ant, Maven, Gradle, SBT, Visual Studio, MSBuild, Bazel, etc.)? For each application you build, specify the NAME of the application, the PLATFORM (multi-select list, e.g. Windows, Mac, linux, etc.) which it is built on, the source control program name which holds this application's source code, the FULL PATH to the build script to build that application, and a default list of people who should be emailed if builds for this application fail. For each build machine (Jenkins slave and/or master), specify the computer NAME or HOST IP and the PLATFORM (multi-select list, e.g. Windows, Mac, Linux, etc.), as well as the source control program name(s) (from a list) which are available on this machine, and the corresponding working copy folder path(s). Do you utilize any container systems (multi-select list, e.g. Docker, Rocket, Drawbridge, Spoon, LXD, etc.)? Do you utilize VM's for post-build installation & testing (multi-select list, e.g. VMware, Hyper-V, AWS EC2, Azure, etc.)? The above question list could be expanded and turned into a 'tree", where certain responses lead to different follow-up questions. In the end, the program would have enough details to implement an initial Jenkins configuration, including plug-ins. A second "job wizard" – or the regular job configuration screen – could then prompt the user to establish a job, e.g. Specify whether this new job will br created "from scratch", or whether it will be based on the settings of an existing job (if any exist). Specify a description for this job. Select the application name and build script (as specified in the first Wizard) for this job Specify any additional command-line parameters for the build script for this job. Select one or more build machine(s) (as specified in the first Wizard) which will build this application. Specify the build frequency / triggers for this job. Specify the path to the primary build log file produced by this build, and whether this log should be attached to any "build failed" email notifications. Specify the path to any unit test output files produced by this build which are in JUnit XML Format. Specify the path to any code coverage output files that a Jenkins plug-in should analyze. Specify email notification options (optionally override defaults setup in the first wizard) Specify any other pre-build or post-build actions. etc.

          Can we save the plugins configurations in an SCM system (like git) and tell jenkins where to get or put those configurations ?

          Pavlos Kleanthous added a comment - Can we save the plugins configurations in an SCM system (like git) and tell jenkins where to get or put those configurations ?

          Daniel Beck added a comment -

          mike4online What is the goal of the workflow you describe? It looks to me like it adds a bunch of complexity and dependencies without really accomplishing anything. A lot of decisions users may not even be equipped to answer are frontloaded. It also assumes a fairly specific and restrictive model of how Jenkins is used.

          Daniel Beck added a comment - mike4online What is the goal of the workflow you describe? It looks to me like it adds a bunch of complexity and dependencies without really accomplishing anything. A lot of decisions users may not even be equipped to answer are frontloaded. It also assumes a fairly specific and restrictive model of how Jenkins is used.

          Daniel Beck added a comment -

          Daniel Beck added a comment - pkleanthous Are you asking for SCM Sync Configuration Plugin ?

          Hi danielbeck,

          The story it's for having jenkins configuration. Like what you can find inside "Manage Jenkins" in a SCM system and can drop them automatically.

          Pavlos Kleanthous added a comment - Hi danielbeck , The story it's for having jenkins configuration. Like what you can find inside "Manage Jenkins" in a SCM system and can drop them automatically.

          Daniel Beck added a comment -

          pkleanthous Right, AFAICT this is what the plugin I link to already does.

          FWIW the trend seems to be towards tools like Chef (rather than plain SCM), and adding a DSL for Jenkins system configuration is currently being considered. Likely won't make it into 2.0 though.

          Daniel Beck added a comment - pkleanthous Right, AFAICT this is what the plugin I link to already does. FWIW the trend seems to be towards tools like Chef (rather than plain SCM), and adding a DSL for Jenkins system configuration is currently being considered. Likely won't make it into 2.0 though.

          Pavlos Kleanthous added a comment - - edited

          Hi danielbeck thanks for the info. You are right this it can be done better via a configuration management tool.

          Pavlos Kleanthous added a comment - - edited Hi danielbeck thanks for the info. You are right this it can be done better via a configuration management tool.

          Michael Litwak added a comment - - edited

          Daniel Beck,

          The intent of having a wizard-guided UI experience for first-time use is to help the user get Jenkins configured quickly, in a manner that suits their needs, without having to fully understand all of the various configuration screens, fields, plug-ins, etc. that they currently need to understand.

          The numbered example items I listed are not fully thought through. They would need to be clarified, expanded, and put into a tree structure, so responses to fundamental questions would lead to more specific questions, and exclude questions that are not applicable. I other words a flowchart-driven set of prompts.

          As for users not being equipped to deal with all the questions that the configuration wizard might present, this is a valid criticism. This can be addressed by providing a worksheet the user can print out, to help them collect the info they'll need to gather before beginning the wizard. Or the wizard can allow responses to be saved at any point, so the wizard can be resumed at a later time and completed once all info is gathered.

          If done poorly, this just creates a redundant set of screens that are harder to use than the existing configuration screens, or leave the system configured only to a small degree. But if implemented well, this could help users get Jenkins up-and-ruinning – in a manner suitable for their organization – very quickly.and easily. Fine-tuning the final configuration – including the addition of various plug-ins and their settings – would be beyond the scope of this initial configuration wizard, and would require the existing UI.

          • Michael

          Michael Litwak added a comment - - edited Daniel Beck, The intent of having a wizard-guided UI experience for first-time use is to help the user get Jenkins configured quickly, in a manner that suits their needs, without having to fully understand all of the various configuration screens, fields, plug-ins, etc. that they currently need to understand. The numbered example items I listed are not fully thought through. They would need to be clarified, expanded, and put into a tree structure, so responses to fundamental questions would lead to more specific questions, and exclude questions that are not applicable. I other words a flowchart-driven set of prompts. As for users not being equipped to deal with all the questions that the configuration wizard might present, this is a valid criticism. This can be addressed by providing a worksheet the user can print out, to help them collect the info they'll need to gather before beginning the wizard. Or the wizard can allow responses to be saved at any point, so the wizard can be resumed at a later time and completed once all info is gathered. If done poorly, this just creates a redundant set of screens that are harder to use than the existing configuration screens, or leave the system configured only to a small degree. But if implemented well, this could help users get Jenkins up-and-ruinning – in a manner suitable for their organization – very quickly.and easily. Fine-tuning the final configuration – including the addition of various plug-ins and their settings – would be beyond the scope of this initial configuration wizard, and would require the existing UI. Michael

          Daniel Beck added a comment -

          Implemented towards Jenkins 2.0

          https://jenkins.io/2.0/

          Daniel Beck added a comment - Implemented towards Jenkins 2.0 https://jenkins.io/2.0/

            Unassigned Unassigned
            kohsuke Kohsuke Kawaguchi
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: