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.