Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-31152

2.0: Pipeline as code in front & center

    Details

    • Epic Name:
      2.0: Pipeline as Code
    • Similar Issues:

      Description

      Problem definition

      The default interaction model with Jenkins has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires large amounts of effort to create and manage jobs to test and build multiple projects and keeps the actual configuration of a job to build/test/deploy a project separate from the actual code being built/tested/deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves.

      Proposal

      Introduce a new subsystem in Jenkins that:

      • lets you design a whole pipeline, not just a single linear set of tasks
      • stores the said pipeline configuration as human-editable Jenkinsfile in your SCM
      • makes it automatic to set up new pipelines when Jenkinsfile is added
      • differentiates multiple branches in the same repository

      This is the key new feature that positions Jenkins for continuous delivery use cases and other more complex automations of today.

      Overview

      (This overview uses GitHub as an example although the system is extensible to allow implementations for other SCMs and repository hostings.)

      1. In this new subsystem, you first let Jenkins know where you host your source code repositories. You do this by creating a new special folder called "Organization Folder" and selecting "GitHub organization." This sets up a new smart folder.
      2. In one of the repository in the chosen org, create a Jenkinsfile that defines your pipeline (or just a build process to start with.) This file is actually a workflow script. See workflow tutorial for details.
      3. Jenkins will automatically recognize this branch and create appropriate jobs by itself.
      4. Everytime a new change is pushed to this branch, the branch is built and the commit status gets updated.
      5. When the branch is destroyed in the repository or if Jenkinsfile is removed, the corresponding job gets destroyed from Jenkins as well automatically.

      In this use, there'll be a lot of Jenkinsfile in various branches & repositories. To keep them DRY, various mechanisms will be provided to promote reuse of workflow scripts, such as this.

      For more details, see Jesse Glick's slides and video recording that talks about this feature (in particular, where the demo starts.) There's also docker-based demo that you can play with on your own.

      Contents

      • Thus, this feature should be made available out of the box by default, unless users opt out (2.0 Out-of-the-box experience)
      • Provide better workflow visualization out of the box (JENKINS-31154)
      • Workflow gets renamed to Pipeline, so that users understand what it is without explanation (JENKINS-31153)
      • Shared library improvements to simplify Jenkinsfile (JENKINS-31155)

      Internals

      • The execution engine of this is Workflow plugin (see JENKINS-26129)
      • Multi-branch workflow project type defines a new kind of folder that is associated with a single source code repository and automatically create/destory a job inside as branches are created/destroyed in the repository.
      • Organization folder that defines a new kind of folder that is associated with a group of source code repositories (such as GitHub org) and automatically create/destory the above "multi-branch workflow project" as repositories are created/destroyed in the group.
      • Branch API plugin and SCM API plugin defines a contract for version control systems (such as Git) and hosting (such as GitHub) to define branch discovery, repository discovery, etc.
      • CloudBees GitHub Branch Source Plugin implements the above contract for GitHub, so that GitHub organization can be added as an organization folder to automatically scan every repo & branch in it. Other similar plugins can be developed for other hosting options and other source code management tools.

      Impact

      Open Questions

        Attachments

          Issue Links

            Activity

            kohsuke Kohsuke Kawaguchi created issue -
            kohsuke Kohsuke Kawaguchi made changes -
            Field Original Value New Value
            Description See [wiki page|http://TODO/] for details. *See [wiki page|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Pipeline+as+Code] for the overview of this epic.
            kohsuke Kohsuke Kawaguchi made changes -
            Description *See [wiki page|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Pipeline+as+Code] for the overview of this epic. *See [wiki page|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Pipeline+as+Code] for the overview of this epic.*
            kohsuke Kohsuke Kawaguchi made changes -
            Epic Child JENKINS-31153 [ 165809 ]
            kohsuke Kohsuke Kawaguchi made changes -
            Description *See [wiki page|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Pipeline+as+Code] for the overview of this epic.* *See [wiki page|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Pipeline+as+Code] for the overview of this epic.*

            This epic is used to track 2.0 planning tickets that are related to pipeline as code in 2.0, so that the next level of details in this plan can be cross-referenced easily. There's no need to link bugs and other tactical changes.
            kohsuke Kohsuke Kawaguchi made changes -
            Epic Child JENKINS-31154 [ 165810 ]
            kohsuke Kohsuke Kawaguchi made changes -
            Epic Child JENKINS-31155 [ 165811 ]
            kohsuke Kohsuke Kawaguchi made changes -
            Epic Name Pipeline as Code 2.0: Pipeline as Code
            gembrotkan Gembrot Bokong made changes -
            Epic Child TEST-56 [ 165828 ]
            waterheaterjakarta waterheaterjakarta made changes -
            Epic Child MEETING-18 [ 165917 ]
            rtyler R. Tyler Croy made changes -
            Description *See [wiki page|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Pipeline+as+Code] for the overview of this epic.*

            This epic is used to track 2.0 planning tickets that are related to pipeline as code in 2.0, so that the next level of details in this plan can be cross-referenced easily. There's no need to link bugs and other tactical changes.
            h1. Problem definition

            The default interaction model with Jenkins has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires large amounts of effort to create and manage jobs to test and build multiple projects and keeps the actual configuration of a job to build/test/deploy a project separate from the actual code being built/tested/deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves.

            h1. Proposal

            Introduce a new subsystem in Jenkins that:

            * lets you design a whole pipeline, not just a single linear set of tasks
            * stores the said pipeline configuration as human-editable Jenkinsfile in your SCM
            * makes it automatic to set up new pipelines when Jenkinsfile is added
            * differentiates multiple branches in the same repository

            This is the key new feature that positions Jenkins for continuous delivery use cases and other more complex automations of today.

            h2. Overview

            (This overview uses GitHub as an example although the system is extensible to allow implementations for other SCMs and repository hostings.)

            # In this new subsystem, you first let Jenkins know where you host your source code repositories. You do this by creating a new special folder called "Organization Folder" and selecting "GitHub organization." This sets up a new smart folder.
            # In one of the repository in the chosen org, create a {{Jenkinsfile}} that defines your pipeline (or just a build process to start with.) This file is actually a workflow script. See [workflow tutorial|https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md] for details.
            # Jenkins will automatically recognize this branch and create appropriate jobs by itself.
            # Everytime a new change is pushed to this branch, the branch is built and the commit status gets updated.
            # When the branch is destroyed in the repository or if {{Jenkinsfile}} is removed, the corresponding job gets destroyed from Jenkins as well automatically.

            In this use, there'll be a lot of {{Jenkinsfile}} in various branches & repositories. To keep them [DRY|https://en.wikipedia.org/wiki/Don%27t_repeat_yourself], various mechanisms will be provided to promote reuse of workflow scripts, such as [this|https://github.com/jenkinsci/workflow-plugin/blob/master/cps-global-lib/README.md].

            For more details, see [~jglick]'s [slides|https://www.cloudbees.com/sites/default/files/webinar-_continuous_delivery_as_code_with_jenkins_workflow.pdf] and [video recording|https://youtu.be/Q2pZdzaaCXg] that talks about this feature (in particular, where [the demo starts|http://www.youtube.com/watch?v=Q2pZdzaaCXg&t=20m30s].) There's also [docker-based demo|https://hub.docker.com/r/cloudbees/github-organization-demo/] that you can play with on your own.


            h2. Contents

            * Thus, this feature should be made available out of the box by default, unless users opt out ([2.0 Out-of-the-box experience])
            * Provide better workflow visualization out of the box (JENKINS-31154)
            * Workflow gets renamed to Pipeline, so that users understand what it is without explanation (JENKINS-31153)
            * Shared library improvements to simplify Jenkinsfile (JENKINS-31155)

            h2. Internals

            * The execution engine of this is [Workflow plugin] (see JENKINS-26129)
            * [Multi-branch workflow project type|https://github.com/jenkinsci/workflow-plugin/tree/master/multibranch] defines a new kind of [folder|CloudBees Folders Plugin] that is associated with a single source code repository and automatically create/destory a job inside as branches are created/destroied in the repository.
            * [Organization folder|https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/OrganizationFolder.java] that defines a new kind of [folder|CloudBees Folders Plugin] that is associated with a group of source code repositories (such as GitHub org) and automatically create/destory the above "multi-branch workflow project" as repositories are created/destroyed in the group.
            * [Branch API plugin] and [SCM API plugin] defines a contract for version control systems (such as Git) and hosting (such as GitHub) to define branch discovery, repository discovery, etc.
            * [CloudBees GitHub Branch Source Plugin] implements the above contract for GitHub, so that GitHub organization can be added as an organization folder to automatically scan every repo & branch in it. Other similar plugins can be developed for other hosting options and other source code management tools.


            h1. Impact


            h1. Open Question
            rtyler R. Tyler Croy made changes -
            Description h1. Problem definition

            The default interaction model with Jenkins has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires large amounts of effort to create and manage jobs to test and build multiple projects and keeps the actual configuration of a job to build/test/deploy a project separate from the actual code being built/tested/deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves.

            h1. Proposal

            Introduce a new subsystem in Jenkins that:

            * lets you design a whole pipeline, not just a single linear set of tasks
            * stores the said pipeline configuration as human-editable Jenkinsfile in your SCM
            * makes it automatic to set up new pipelines when Jenkinsfile is added
            * differentiates multiple branches in the same repository

            This is the key new feature that positions Jenkins for continuous delivery use cases and other more complex automations of today.

            h2. Overview

            (This overview uses GitHub as an example although the system is extensible to allow implementations for other SCMs and repository hostings.)

            # In this new subsystem, you first let Jenkins know where you host your source code repositories. You do this by creating a new special folder called "Organization Folder" and selecting "GitHub organization." This sets up a new smart folder.
            # In one of the repository in the chosen org, create a {{Jenkinsfile}} that defines your pipeline (or just a build process to start with.) This file is actually a workflow script. See [workflow tutorial|https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md] for details.
            # Jenkins will automatically recognize this branch and create appropriate jobs by itself.
            # Everytime a new change is pushed to this branch, the branch is built and the commit status gets updated.
            # When the branch is destroyed in the repository or if {{Jenkinsfile}} is removed, the corresponding job gets destroyed from Jenkins as well automatically.

            In this use, there'll be a lot of {{Jenkinsfile}} in various branches & repositories. To keep them [DRY|https://en.wikipedia.org/wiki/Don%27t_repeat_yourself], various mechanisms will be provided to promote reuse of workflow scripts, such as [this|https://github.com/jenkinsci/workflow-plugin/blob/master/cps-global-lib/README.md].

            For more details, see [~jglick]'s [slides|https://www.cloudbees.com/sites/default/files/webinar-_continuous_delivery_as_code_with_jenkins_workflow.pdf] and [video recording|https://youtu.be/Q2pZdzaaCXg] that talks about this feature (in particular, where [the demo starts|http://www.youtube.com/watch?v=Q2pZdzaaCXg&t=20m30s].) There's also [docker-based demo|https://hub.docker.com/r/cloudbees/github-organization-demo/] that you can play with on your own.


            h2. Contents

            * Thus, this feature should be made available out of the box by default, unless users opt out ([2.0 Out-of-the-box experience])
            * Provide better workflow visualization out of the box (JENKINS-31154)
            * Workflow gets renamed to Pipeline, so that users understand what it is without explanation (JENKINS-31153)
            * Shared library improvements to simplify Jenkinsfile (JENKINS-31155)

            h2. Internals

            * The execution engine of this is [Workflow plugin] (see JENKINS-26129)
            * [Multi-branch workflow project type|https://github.com/jenkinsci/workflow-plugin/tree/master/multibranch] defines a new kind of [folder|CloudBees Folders Plugin] that is associated with a single source code repository and automatically create/destory a job inside as branches are created/destroied in the repository.
            * [Organization folder|https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/OrganizationFolder.java] that defines a new kind of [folder|CloudBees Folders Plugin] that is associated with a group of source code repositories (such as GitHub org) and automatically create/destory the above "multi-branch workflow project" as repositories are created/destroyed in the group.
            * [Branch API plugin] and [SCM API plugin] defines a contract for version control systems (such as Git) and hosting (such as GitHub) to define branch discovery, repository discovery, etc.
            * [CloudBees GitHub Branch Source Plugin] implements the above contract for GitHub, so that GitHub organization can be added as an organization folder to automatically scan every repo & branch in it. Other similar plugins can be developed for other hosting options and other source code management tools.


            h1. Impact


            h1. Open Question
            h1. Problem definition

            The default interaction model with Jenkins has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires large amounts of effort to create and manage jobs to test and build multiple projects and keeps the actual configuration of a job to build/test/deploy a project separate from the actual code being built/tested/deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves.

            h1. Proposal

            Introduce a new subsystem in Jenkins that:

            * lets you design a whole pipeline, not just a single linear set of tasks
            * stores the said pipeline configuration as human-editable Jenkinsfile in your SCM
            * makes it automatic to set up new pipelines when Jenkinsfile is added
            * differentiates multiple branches in the same repository

            This is the key new feature that positions Jenkins for continuous delivery use cases and other more complex automations of today.

            h2. Overview

            (This overview uses GitHub as an example although the system is extensible to allow implementations for other SCMs and repository hostings.)

            # In this new subsystem, you first let Jenkins know where you host your source code repositories. You do this by creating a new special folder called "Organization Folder" and selecting "GitHub organization." This sets up a new smart folder.
            # In one of the repository in the chosen org, create a {{Jenkinsfile}} that defines your pipeline (or just a build process to start with.) This file is actually a workflow script. See [workflow tutorial|https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md] for details.
            # Jenkins will automatically recognize this branch and create appropriate jobs by itself.
            # Everytime a new change is pushed to this branch, the branch is built and the commit status gets updated.
            # When the branch is destroyed in the repository or if {{Jenkinsfile}} is removed, the corresponding job gets destroyed from Jenkins as well automatically.

            In this use, there'll be a lot of {{Jenkinsfile}} in various branches & repositories. To keep them [DRY|https://en.wikipedia.org/wiki/Don%27t_repeat_yourself], various mechanisms will be provided to promote reuse of workflow scripts, such as [this|https://github.com/jenkinsci/workflow-plugin/blob/master/cps-global-lib/README.md].

            For more details, see [~jglick]'s [slides|https://www.cloudbees.com/sites/default/files/webinar-_continuous_delivery_as_code_with_jenkins_workflow.pdf] and [video recording|https://youtu.be/Q2pZdzaaCXg] that talks about this feature (in particular, where [the demo starts|http://www.youtube.com/watch?v=Q2pZdzaaCXg&t=20m30s].) There's also [docker-based demo|https://hub.docker.com/r/cloudbees/github-organization-demo/] that you can play with on your own.


            h2. Contents

            * Thus, this feature should be made available out of the box by default, unless users opt out ([2.0 Out-of-the-box experience|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Out-of-the-box+experience])
            * Provide better workflow visualization out of the box (JENKINS-31154)
            * Workflow gets renamed to Pipeline, so that users understand what it is without explanation (JENKINS-31153)
            * Shared library improvements to simplify Jenkinsfile (JENKINS-31155)

            h2. Internals

            * The execution engine of this is [Workflow plugin|https://wiki.jenkins-ci.org/display/JENKINS/Workflow+Plugin] (see JENKINS-26129)
            * [Multi-branch workflow project type|https://github.com/jenkinsci/workflow-plugin/tree/master/multibranch] defines a new kind of [folder|CloudBees Folders Plugin] that is associated with a single source code repository and automatically create/destory a job inside as branches are created/destroied in the repository.
            * [Organization folder|https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/OrganizationFolder.java] that defines a new kind of [folder|CloudBees Folders Plugin] that is associated with a group of source code repositories (such as GitHub org) and automatically create/destory the above "multi-branch workflow project" as repositories are created/destroyed in the group.
            * [Branch API plugin|https://wiki.jenkins-ci.org/display/JENKINS/Branch+API+Plugin] and [SCM API plugin|https://wiki.jenkins-ci.org/display/JENKINS/SCM+API+Plugin] defines a contract for version control systems (such as Git) and hosting (such as GitHub) to define branch discovery, repository discovery, etc.
            * [CloudBees GitHub Branch Source Plugin|https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+GitHub+Branch+Source+Plugin] implements the above contract for GitHub, so that GitHub organization can be added as an organization folder to automatically scan every repo & branch in it. Other similar plugins can be developed for other hosting options and other source code management tools.


            h1. Impact


            h1. Open Question
            rtyler R. Tyler Croy made changes -
            Description h1. Problem definition

            The default interaction model with Jenkins has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires large amounts of effort to create and manage jobs to test and build multiple projects and keeps the actual configuration of a job to build/test/deploy a project separate from the actual code being built/tested/deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves.

            h1. Proposal

            Introduce a new subsystem in Jenkins that:

            * lets you design a whole pipeline, not just a single linear set of tasks
            * stores the said pipeline configuration as human-editable Jenkinsfile in your SCM
            * makes it automatic to set up new pipelines when Jenkinsfile is added
            * differentiates multiple branches in the same repository

            This is the key new feature that positions Jenkins for continuous delivery use cases and other more complex automations of today.

            h2. Overview

            (This overview uses GitHub as an example although the system is extensible to allow implementations for other SCMs and repository hostings.)

            # In this new subsystem, you first let Jenkins know where you host your source code repositories. You do this by creating a new special folder called "Organization Folder" and selecting "GitHub organization." This sets up a new smart folder.
            # In one of the repository in the chosen org, create a {{Jenkinsfile}} that defines your pipeline (or just a build process to start with.) This file is actually a workflow script. See [workflow tutorial|https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md] for details.
            # Jenkins will automatically recognize this branch and create appropriate jobs by itself.
            # Everytime a new change is pushed to this branch, the branch is built and the commit status gets updated.
            # When the branch is destroyed in the repository or if {{Jenkinsfile}} is removed, the corresponding job gets destroyed from Jenkins as well automatically.

            In this use, there'll be a lot of {{Jenkinsfile}} in various branches & repositories. To keep them [DRY|https://en.wikipedia.org/wiki/Don%27t_repeat_yourself], various mechanisms will be provided to promote reuse of workflow scripts, such as [this|https://github.com/jenkinsci/workflow-plugin/blob/master/cps-global-lib/README.md].

            For more details, see [~jglick]'s [slides|https://www.cloudbees.com/sites/default/files/webinar-_continuous_delivery_as_code_with_jenkins_workflow.pdf] and [video recording|https://youtu.be/Q2pZdzaaCXg] that talks about this feature (in particular, where [the demo starts|http://www.youtube.com/watch?v=Q2pZdzaaCXg&t=20m30s].) There's also [docker-based demo|https://hub.docker.com/r/cloudbees/github-organization-demo/] that you can play with on your own.


            h2. Contents

            * Thus, this feature should be made available out of the box by default, unless users opt out ([2.0 Out-of-the-box experience|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Out-of-the-box+experience])
            * Provide better workflow visualization out of the box (JENKINS-31154)
            * Workflow gets renamed to Pipeline, so that users understand what it is without explanation (JENKINS-31153)
            * Shared library improvements to simplify Jenkinsfile (JENKINS-31155)

            h2. Internals

            * The execution engine of this is [Workflow plugin|https://wiki.jenkins-ci.org/display/JENKINS/Workflow+Plugin] (see JENKINS-26129)
            * [Multi-branch workflow project type|https://github.com/jenkinsci/workflow-plugin/tree/master/multibranch] defines a new kind of [folder|CloudBees Folders Plugin] that is associated with a single source code repository and automatically create/destory a job inside as branches are created/destroied in the repository.
            * [Organization folder|https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/OrganizationFolder.java] that defines a new kind of [folder|CloudBees Folders Plugin] that is associated with a group of source code repositories (such as GitHub org) and automatically create/destory the above "multi-branch workflow project" as repositories are created/destroyed in the group.
            * [Branch API plugin|https://wiki.jenkins-ci.org/display/JENKINS/Branch+API+Plugin] and [SCM API plugin|https://wiki.jenkins-ci.org/display/JENKINS/SCM+API+Plugin] defines a contract for version control systems (such as Git) and hosting (such as GitHub) to define branch discovery, repository discovery, etc.
            * [CloudBees GitHub Branch Source Plugin|https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+GitHub+Branch+Source+Plugin] implements the above contract for GitHub, so that GitHub organization can be added as an organization folder to automatically scan every repo & branch in it. Other similar plugins can be developed for other hosting options and other source code management tools.


            h1. Impact


            h1. Open Question
            h1. Problem definition

            The default interaction model with Jenkins has been very web UI driven, requiring users to manually create jobs, then manually fill in the details through a web browser. This requires large amounts of effort to create and manage jobs to test and build multiple projects and keeps the actual configuration of a job to build/test/deploy a project separate from the actual code being built/tested/deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves.

            h1. Proposal

            Introduce a new subsystem in Jenkins that:

            * lets you design a whole pipeline, not just a single linear set of tasks
            * stores the said pipeline configuration as human-editable Jenkinsfile in your SCM
            * makes it automatic to set up new pipelines when Jenkinsfile is added
            * differentiates multiple branches in the same repository

            This is the key new feature that positions Jenkins for continuous delivery use cases and other more complex automations of today.

            h2. Overview

            (This overview uses GitHub as an example although the system is extensible to allow implementations for other SCMs and repository hostings.)

            # In this new subsystem, you first let Jenkins know where you host your source code repositories. You do this by creating a new special folder called "Organization Folder" and selecting "GitHub organization." This sets up a new smart folder.
            # In one of the repository in the chosen org, create a {{Jenkinsfile}} that defines your pipeline (or just a build process to start with.) This file is actually a workflow script. See [workflow tutorial|https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md] for details.
            # Jenkins will automatically recognize this branch and create appropriate jobs by itself.
            # Everytime a new change is pushed to this branch, the branch is built and the commit status gets updated.
            # When the branch is destroyed in the repository or if {{Jenkinsfile}} is removed, the corresponding job gets destroyed from Jenkins as well automatically.

            In this use, there'll be a lot of {{Jenkinsfile}} in various branches & repositories. To keep them [DRY|https://en.wikipedia.org/wiki/Don%27t_repeat_yourself], various mechanisms will be provided to promote reuse of workflow scripts, such as [this|https://github.com/jenkinsci/workflow-plugin/blob/master/cps-global-lib/README.md].

            For more details, see [~jglick]'s [slides|https://www.cloudbees.com/sites/default/files/webinar-_continuous_delivery_as_code_with_jenkins_workflow.pdf] and [video recording|https://youtu.be/Q2pZdzaaCXg] that talks about this feature (in particular, where [the demo starts|http://www.youtube.com/watch?v=Q2pZdzaaCXg&t=20m30s].) There's also [docker-based demo|https://hub.docker.com/r/cloudbees/github-organization-demo/] that you can play with on your own.


            h2. Contents

            * Thus, this feature should be made available out of the box by default, unless users opt out ([2.0 Out-of-the-box experience|https://wiki.jenkins-ci.org/display/JENKINS/2.0+Out-of-the-box+experience])
            * Provide better workflow visualization out of the box (JENKINS-31154)
            * Workflow gets renamed to Pipeline, so that users understand what it is without explanation (JENKINS-31153)
            * Shared library improvements to simplify Jenkinsfile (JENKINS-31155)

            h2. Internals

            * The execution engine of this is [Workflow plugin|https://wiki.jenkins-ci.org/display/JENKINS/Workflow+Plugin] (see JENKINS-26129)
            * [Multi-branch workflow project type|https://github.com/jenkinsci/workflow-plugin/tree/master/multibranch] defines a new kind of [folder|https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Folders+Plugin] that is associated with a single source code repository and automatically create/destory a job inside as branches are created/destroyed in the repository.
            * [Organization folder|https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/OrganizationFolder.java] that defines a new kind of [folder|https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Folders+Plugin] that is associated with a group of source code repositories (such as GitHub org) and automatically create/destory the above "multi-branch workflow project" as repositories are created/destroyed in the group.
            * [Branch API plugin|https://wiki.jenkins-ci.org/display/JENKINS/Branch+API+Plugin] and [SCM API plugin|https://wiki.jenkins-ci.org/display/JENKINS/SCM+API+Plugin] defines a contract for version control systems (such as Git) and hosting (such as GitHub) to define branch discovery, repository discovery, etc.
            * [CloudBees GitHub Branch Source Plugin|https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+GitHub+Branch+Source+Plugin] implements the above contract for GitHub, so that GitHub organization can be added as an organization folder to automatically scan every repo & branch in it. Other similar plugins can be developed for other hosting options and other source code management tools.


            h1. Impact


            h1. Open Questions
            solahartwater solahartwater made changes -
            Epic Child INFRA-442 [ 165957 ]
            solahartwater solahartwater made changes -
            Epic Child INFRA-443 [ 165958 ]
            solahartwater solahartwater made changes -
            Epic Child INFRA-447 [ 165962 ]
            solahartwater solahartwater made changes -
            Epic Child INFRA-451 [ 165966 ]
            solahartwater solahartwater made changes -
            Epic Child INFRA-452 [ 165967 ]
            solahartwater solahartwater made changes -
            Epic Child INFRA-453 [ 165968 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-24 [ 166332 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-25 [ 166333 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-26 [ 166334 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-27 [ 166335 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-28 [ 166336 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-29 [ 166337 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-30 [ 166338 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-31 [ 166339 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-32 [ 166340 ]
            jakartaservice jakartaservice made changes -
            Epic Child WEBSITE-33 [ 166341 ]
            raphc Raphael CHAUMIER made changes -
            Comment [ +1 ]
            yogiteches neel maity (Inactive) made changes -
            Epic Child INFRA-538 [ 167432 ]
            okram999 Niristotle Okram made changes -
            Epic Child JENKINS-32937 [ 168153 ]
            orrc Christopher Orr made changes -
            Epic Child JENKINS-32937 [ 168153 ]
            jglick Jesse Glick made changes -
            Epic Child JENKINS-33106 [ 168473 ]
            rtyler R. Tyler Croy made changes -
            Link This issue is blocking JENKINS-33281 [ JENKINS-33281 ]
            jglick Jesse Glick made changes -
            Assignee Jesse Glick [ jglick ] Daniel Beck [ danielbeck ]
            jglick Jesse Glick made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            michaelhuettermann Michael Hüttermann made changes -
            Epic Child JENKINS-33837 [ 169313 ]
            michaelhuettermann Michael Hüttermann made changes -
            Epic Child JENKINS-33840 [ 169316 ]
            michaelhuettermann Michael Hüttermann made changes -
            Epic Child JENKINS-33842 [ 169318 ]
            jglick Jesse Glick made changes -
            Epic Child JENKINS-33837 [ 169313 ]
            dpd_30 Daniel Daugherty made changes -
            Epic Child JENKINS-34150 [ 169676 ]
            drieselliott Dries Elliott made changes -
            Epic Child JENKINS-34163 [ 169690 ]
            jknurek J Knurek made changes -
            Epic Child JENKINS-34506 [ 170110 ]
            jknurek J Knurek made changes -
            Epic Child JENKINS-34507 [ 170111 ]
            m_k Michael Krause made changes -
            Epic Child JENKINS-34567 [ 170185 ]
            kohsuke Kohsuke Kawaguchi made changes -
            Status In Progress [ 3 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            jglick Jesse Glick made changes -
            Epic Child JENKINS-31155 [ 165811 ]
            jamesdelvin02 James Delvin made changes -
            Epic Child INFRA-817 [ 172188 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 166332 ] JNJira + In-Review [ 197979 ]
            abayer Andrew Bayer made changes -
            Component/s pipeline-general [ 21692 ]
            abayer Andrew Bayer made changes -
            Component/s workflow-plugin [ 18820 ]
            mkasberg Mike Kasberg made changes -
            Epic Child JENKINS-38046 [ 174194 ]
            peternhale Pete Hale made changes -
            Epic Child JENKINS-38454 [ 174634 ]
            abayer Andrew Bayer made changes -
            Epic Child JENKINS-38454 [ 174634 ]
            marcelfrei_ublox Marcel Frei made changes -
            Assignee Daniel Beck [ danielbeck ] Marcel Frei [ marcelfrei_ublox ]
            robert_ilg Robert Ilg made changes -
            Epic Child JENKINS-38742 [ 175142 ]
            asreenivas sree nivas made changes -
            Epic Child JENKINS-39900 [ 176519 ]
            deshari143 satish k made changes -
            Epic Child JENKINS-40889 [ 177611 ]
            atulsharma1989 Atul Sharma made changes -
            Epic Child EVENTS-43 [ 178147 ]
            saranya2293 Saranya U made changes -
            Epic Child JENKINS-43420 [ 180664 ]
            phani_kumar Phani Kumar made changes -
            Epic Child JENKINS-44695 [ 182559 ]
            phani_kumar Phani Kumar made changes -
            Epic Child JENKINS-44695 [ 182559 ]
            maneeshmp Maneesh M P made changes -
            Epic Child JENKINS-45418 [ 183586 ]
            jamesdumay James Dumay made changes -
            Epic Child JENKINS-43420 [ 180664 ]
            jamesdumay James Dumay made changes -
            Epic Status To Do [ 10000 ] Done [ 10002 ]

              People

              • Assignee:
                marcelfrei_ublox Marcel Frei
                Reporter:
                kohsuke Kohsuke Kawaguchi
              • Votes:
                25 Vote for this issue
                Watchers:
                24 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: