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

Make git plugin browser URL guessing clearer and easier to understand

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      Git plugin versions prior to git plugin 3.7.0 will infer the browser URL if the repository URL is a github.com URL. Git plugin 3.7.0 added browser URL inference for bitbucket.org and gitlab.com URL's.

      Stephen Connolly suggested that it would be clearer if the inference were made apparent to the user, rather than being hidden inside the plugin logic. He suggested:

      1. For regular SCM in old-style jobs... if you see the url as well-known, and the user has not configured a browser, then replace their no-browser with the well-known one in the constructor
      2. We don't need to do anything for SCMSource impls as they have their own pre-configured subclasses that do the right thing
      3. For the `git` pipeline step, have it do the inference and log the inference to the build log
      4. Make the inference logic an ExtensionPoint

          [JENKINS-48822] Make git plugin browser URL guessing clearer and easier to understand

          Mark Waite created issue -
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]
          Mark Waite made changes -
          Labels New: newbie-friendly

          I want to contribute on this issue. From where should I start ?

          Gyanesha Prajjwal added a comment - I want to contribute on this issue. From where should I start ?

          Mark Waite added a comment - - edited

          Thanks for your desire to contribute on this issue. That is wonderful!

          I think you should take the following steps:

          1. Assign the issue to yourself and change its state to "In Progress" so that others know you are working on it
          2. Clone and compile the git plugin based on the contributing guide
          3. Use the Jenkins git-plugin gitter channel for conversations as you progress in the implementation
          4. Identify the location in the GitSCM constructor where Freestyle ("old style") jobs determine the browser is "no browser" and replace it with inference logic based on the repository URL
          5. Investigate if the GitStep can be extended to infer the browser class from the repository URL as well. Do not be concerned if the GitStep is not readily modified or if changes to the GitStep are rejected. If is a legacy of the original pipeline implementation which has been superseded by the much more powerful checkout step
          6. Review existing extension points in the git plugin. Likely best to model this one after BuildChooser
          7. Define a Jenkins extension point for the browser inference logic inside the git plugin (see Defining an extension point)
          8. Write automated tests to learn the code and to express what you've learned as code while making the changes

          Mark Waite added a comment - - edited Thanks for your desire to contribute on this issue. That is wonderful! I think you should take the following steps: Assign the issue to yourself and change its state to "In Progress" so that others know you are working on it Clone and compile the git plugin based on the contributing guide Use the Jenkins git-plugin gitter channel for conversations as you progress in the implementation Identify the location in the GitSCM constructor where Freestyle ("old style") jobs determine the browser is "no browser" and replace it with inference logic based on the repository URL Investigate if the GitStep can be extended to infer the browser class from the repository URL as well. Do not be concerned if the GitStep is not readily modified or if changes to the GitStep are rejected. If is a legacy of the original pipeline implementation which has been superseded by the much more powerful checkout step Review existing extension points in the git plugin. Likely best to model this one after BuildChooser Define a Jenkins extension point for the browser inference logic inside the git plugin (see Defining an extension point ) Write automated tests to learn the code and to express what you've learned as code while making the changes
          Gyanesha Prajjwal made changes -
          Assignee New: Gyanesha Prajjwal [ spectre009 ]
          Gyanesha Prajjwal made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          What is browser URL here, is it same as web URL.

          Gyanesha Prajjwal added a comment - What is browser URL here, is it same as web URL.

          So, you mean I need to make certain changes, such that instead of "(Auto)" it should show the inferred browser repository in SCM.

          Gyanesha Prajjwal added a comment - So, you mean I need to make certain changes, such that instead of "(Auto)" it should show the inferred browser repository in SCM.

          Mark Waite added a comment -

          Yes, I believe that will be one of the results of setting the browser in the constructor when the repository URL is a recognized URL.

          The constructor would continue to be called with the same arguments it has today. Inside the constructor, there would be a call to decide if the repository URL is a recognized URL. That call would be an extension point which is used by the git plugin to register the recognized URLs. Since it would be an extension point, other plugins could add their own recognized URLs without requiring changes to the git plugin.

          There is a page that describes how to define a new extension point. Refer to the current Jenkins extension points for possible reference implementations. The RepositoryBrowser is an extension point that is implemented in the git plugin repository browsers. I've never created a new extension point, so this will be a learning experience for me as well.

          Mark Waite added a comment - Yes, I believe that will be one of the results of setting the browser in the constructor when the repository URL is a recognized URL. The constructor would continue to be called with the same arguments it has today. Inside the constructor, there would be a call to decide if the repository URL is a recognized URL. That call would be an extension point which is used by the git plugin to register the recognized URLs. Since it would be an extension point, other plugins could add their own recognized URLs without requiring changes to the git plugin. There is a page that describes how to define a new extension point . Refer to the current Jenkins extension points for possible reference implementations. The RepositoryBrowser is an extension point that is implemented in the git plugin repository browsers. I've never created a new extension point, so this will be a learning experience for me as well.

            Unassigned Unassigned
            markewaite Mark Waite
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: