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

Multi-branch pipelines opened in the Editor are unable to display the correct default branch in the save dialog

    Details

    • Similar Issues:
    • Sprint:
      Blue Ocean 1.2, Blue Ocean - Candidates

      Description

      For GitHub pipelines created as Org Folders, the Editor is launched with a "pipeline" parameter in the form of :orgFolderName/:pipelineName which matches the GitHub org name and repository name, respectively. The editor would use these values to call into the /scm/organizations/:orgName/repositories/:repoName REST API to retrieve the name of the default branch. This is used in the save dialog to show the name of the default branch that the user can save to.

      For multi-branch pipelines, there is no concept of an orgFolderName, and as such the fetch to the above REST API fails with a 404, which triggers an error handler that sets the default branch to "master".

      Since there is not necessarily an obvious fix to this bug I figured it could serve first as a place for discussion and then the ticket can be written up later to describe a bug or enhancement. Bear in mind that once JENKINS-45240 is implemented, all pipelines created via Creation will be multi-branch rather than org folders, so this issue will be more widespread.

      Possibilities:

      1. Enhance the metadata model of multibranch pipeline to include the default branch. I know there was discussion of this in the past and I seem to recall that branch source or other upstream plugins didn't expose this data. Maybe that's changed since then?
      2. Add a new :pipeline/scm/metadata REST API to return the branch name. The backend would make a request to GitHub similar to what the /scm/organizations/... endpoint is already doing, but the client would not need to know the org name or repo name.
      3. Change the save dialog so it doesn't display the name of the default branch but instead simply says "default branch" - worse UX, but eliminates the problem entirely.
      4. Find some way to store the org name and repo name in the multibranch pipeline itself when it's created and then expose it in the metadata model (as in #1)

      Caveats

      1. We need to consider how to handle this for plain Git repos too. That /scm/organizations/... API is meaningless in a pure Git world.

        Attachments

          Activity

          Hide
          cliffmeyers Cliff Meyers added a comment -
          Show
          cliffmeyers Cliff Meyers added a comment - cc James Dumay and Vivek Pandey
          Hide
          jamesdumay James Dumay added a comment -

          Vivek Pandey sounds like a good one to look into when tearing out org folders.

          Show
          jamesdumay James Dumay added a comment - Vivek Pandey sounds like a good one to look into when tearing out org folders.
          Hide
          michaelneale Michael Neale added a comment -

          Cliff Meyers is this still relevant in a 1.3 world? 

          Show
          michaelneale Michael Neale added a comment - Cliff Meyers is this still relevant in a 1.3 world? 
          Hide
          cliffmeyers Cliff Meyers added a comment -

          Michael Neale I believe it's even more relevant as this impacts anything created as a MBP pipeline.

          Show
          cliffmeyers Cliff Meyers added a comment - Michael Neale I believe it's even more relevant as this impacts anything created as a MBP pipeline.

            People

            • Assignee:
              Unassigned
              Reporter:
              cliffmeyers Cliff Meyers
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: