Details

    • Epic Link:
    • Sprint:
      Blue Ocean 1.2-beta4, Blue Ocean 1.2
    • Similar Issues:

      Description

      Scope

      • Remove the concept of organisation folders from creation
      • Use the same duplication resolution used by the Git option in creation

      Problem
      If a user attempts to create pipelines from repos that belong to the same organization name across multiple GitHub servers, the pipeline creation will not succeed.

      Presently, all GitHub-created pipelines are stored in a GitHub OrganizationFolder in the root of the Jenkins organization. The folder name is the name of the GitHub org. If a user creates a pipeline from "myorg/repo1" on GH server A, then attempts to create a piepline from "myorg/repo2" on GH server B, the original org folder will be updated to scan for "myorg/repo2" on server A.

      This can occur if the instance is using either (A) more than one GHE server, or (B) github.com and one or more GHE servers.

      Note
      One way to address this bug would be to rework the org folder implementation to just create standalone multi-branch pipelines and handle renaming similar to Git-based pipeline creation.

      Potential Fix
      The suggested fix is to allow the user the rename the org folder to keep them isolated from one another. There are some challenges with this approach:

      • Once the user picks an org in the UI, it makes a fetch to "organizations/jenkins/$orgname" to check whether the org folder exists, which impacts some downstream logic. If org folders can be renamed, there is no naming convention the UI can rely upon. We would need a new service to query for org folders - the search API might already support this. A "match" would be driven by the SCM API URL and the organization name.
      • We would need to expose the SCM API URL on the "OrganizationFolderPipelineImpl" class. It already contains an "organization" property. Presumably there is some way to get at the SCM API URL from the underlying "OrganizationFolder" class.
      • BluePipelineCreateRequest already supports specifying an arbitrary name for the org folder via its "name" property. However, once the request is submitted, GithubPipelineCreateRequest first checks for an existing org folder in the root with that name. If it exists, it goes into "update mode" and if not it goes into "create mode". This logic would need to be enhanced to take the SCM API URL into account as well.
        • If request's "name" property is not in use, just go to create mode.
        • If request's "name" property is in use, and the submitted organization name and SCM API URL match those in the existing org folder, then go to "update" mode.
        • If request's "name" property is in use, and the above properties not match, then throw a 400 with "ALREADY_EXISTS" and allow the user to rename via the UI.

        Attachments

          Issue Links

            Activity

            Hide
            jamesdumay James Dumay added a comment -

            FYI Vivek Pandey after Bitbucket and Stephens new branch source work lands, this is next off the queue for you.

            Show
            jamesdumay James Dumay added a comment - FYI Vivek Pandey after Bitbucket and Stephens new branch source work lands, this is next off the queue for you.
            Hide
            michaelneale Michael Neale added a comment -

            FYI https://github.com/jenkinsci/blueocean-plugin/pull/1188 - may be relevant, or not, based on this 

            Show
            michaelneale Michael Neale added a comment - FYI https://github.com/jenkinsci/blueocean-plugin/pull/1188  - may be relevant, or not, based on this 
            Hide
            michaelneale Michael Neale added a comment -

            may want to consider looking for use of restricted api as part of this. 

            Show
            michaelneale Michael Neale added a comment - may want to consider looking for use of restricted api as part of this. 
            Hide
            mcsf M Chon added a comment - - edited

            I would like to be able to globally disable Github Organization Projects altogether. I do not want end users to be able to create a GO project, but still allow them to create Multibranch Pipeline projects. Should I file a separate bug for this request? E.g. If all 1000+ repos in my (GHE) org one day have a Jenkinsfile added to them, I do NOT want a job which starts scanning them and automatically building.

            Show
            mcsf M Chon added a comment - - edited I would like to be able to globally disable Github Organization Projects altogether. I do not want end users to be able to create a GO project, but still allow them to create Multibranch Pipeline projects. Should I file a separate bug for this request? E.g. If all 1000+ repos in my (GHE) org one day have a Jenkinsfile added to them, I do NOT want a job which starts scanning them and automatically building.

              People

              • Assignee:
                vivek Vivek Pandey
                Reporter:
                cliffmeyers Cliff Meyers
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: