Details

    • Type: Epic
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
    • Epic Name:
      2.0: Out of the box experience
    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            kohsuke Kohsuke Kawaguchi created issue -
            kohsuke Kohsuke Kawaguchi made changes -
            Field Original Value New Value
            Epic Child JENKINS-9598 [ 139765 ]
            kohsuke Kohsuke Kawaguchi made changes -
            Epic Child JENKINS-30749 [ 165363 ]
            hrmpw Patrick Wolf made changes -
            Epic Child JENKINS-31162 [ 165819 ]
            hrmpw Patrick Wolf made changes -
            Epic Child JENKINS-31176 [ 165835 ]
            aarondmarasco_vsi Aaron D. Marasco made changes -
            Epic Child JENKINS-31255 [ 165981 ]
            rtyler R. Tyler Croy made changes -
            Description * See [wiki|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Out-of-the-box+experience] for the context and the background*

            This epic is tracking 2.0 planning tickets that are around the out of the box product experience, so that new users can start using Jenkins, without assembling pieces first.
            h1. 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.


            h1. Proposal


            h1. Impact


            h1. Open Questions



            This epic is tracking 2.0 planning tickets that are around the out of the box product experience, so that new users can start using Jenkins, without assembling pieces first.
            rtyler R. Tyler Croy made changes -
            Description h1. 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.


            h1. Proposal


            h1. Impact


            h1. Open Questions



            This epic is tracking 2.0 planning tickets that are around the out of the box product experience, so that new users can start using Jenkins, without assembling pieces first.
            h1. 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.


            h1. 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.

            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|https://jenkins-ci.org/content/jenkins-20-proposal-pipeline-code-front-and-center]

            h1. Impact

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

            h1. Open Questions

            *
            rtyler R. Tyler Croy made changes -
            Description h1. 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.


            h1. 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.

            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|https://jenkins-ci.org/content/jenkins-20-proposal-pipeline-code-front-and-center]

            h1. Impact

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

            h1. Open Questions

            *
            h1. 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.


            h1. 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|https://jenkins-ci.org/content/jenkins-20-proposal-pipeline-code-front-and-center]

            h1. Impact

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

            h1. Open Questions

            *
            servicesolahartbekasi servicesolahartbekasi made changes -
            Epic Child INFRA-459 [ 166247 ]
            Hide
            mike4online 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.
            Show
            mike4online 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.
            Hide
            pkleanthous 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 ?

            Show
            pkleanthous 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 ?
            Hide
            danielbeck Daniel Beck added a comment -

            Michael Litwak 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.

            Show
            danielbeck Daniel Beck added a comment - Michael Litwak 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.
            Hide
            danielbeck Daniel Beck added a comment -
            Show
            danielbeck Daniel Beck added a comment - Pavlos Kleanthous Are you asking for SCM Sync Configuration Plugin ?
            Hide
            pkleanthous Pavlos Kleanthous added a comment -

            Hi Daniel Beck,

            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.

            Show
            pkleanthous Pavlos Kleanthous added a comment - Hi Daniel Beck , 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.
            Hide
            danielbeck Daniel Beck added a comment -

            Pavlos Kleanthous 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.

            Show
            danielbeck Daniel Beck added a comment - Pavlos Kleanthous 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.
            Hide
            pkleanthous Pavlos Kleanthous added a comment - - edited

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

            Show
            pkleanthous Pavlos Kleanthous added a comment - - edited Hi Daniel Beck thanks for the info. You are right this it can be done better via a configuration management tool.
            Hide
            mike4online 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
            Show
            mike4online 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
            saptarshimandal SAPTARSHI MANDAL made changes -
            Epic Child JENKINS-31872 [ 166825 ]
            oleg_nenashev Oleg Nenashev made changes -
            Epic Child JENKINS-31872 [ 166825 ]
            fredericmeyrou Frédéric Meyrou made changes -
            Epic Child JENKINS-32333 [ 167441 ]
            kevlo Kevin Lourenco made changes -
            Epic Child JENKINS-32563 [ 167705 ]
            rtyler R. Tyler Croy made changes -
            Link This issue is blocking JENKINS-33281 [ JENKINS-33281 ]
            jyrkip Jyrki Puttonen made changes -
            Epic Child JENKINS-33334 [ 168735 ]
            rtyler R. Tyler Croy made changes -
            Epic Child JENKINS-33462 [ 168875 ]
            rtyler R. Tyler Croy made changes -
            Epic Child JENKINS-33464 [ 168877 ]
            orrc Christopher Orr made changes -
            Epic Child JENKINS-31255 [ 165981 ]
            orrc Christopher Orr made changes -
            Epic Child JENKINS-32333 [ 167441 ]
            orrc Christopher Orr made changes -
            Epic Child JENKINS-32563 [ 167705 ]
            Hide
            danielbeck Daniel Beck added a comment -

            Implemented towards Jenkins 2.0

            https://jenkins.io/2.0/

            Show
            danielbeck Daniel Beck added a comment - Implemented towards Jenkins 2.0 https://jenkins.io/2.0/
            danielbeck Daniel Beck made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 166337 ] JNJira + In-Review [ 197981 ]
            veeresh667 Veeresh r made changes -
            Epic Child JENKINS-41241 [ 178006 ]
            stevench2000 Steven Chen made changes -
            Epic Child JENKINS-42974 [ 179987 ]

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: