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

          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

          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.

          Gyanesha Prajjwal added a comment - - edited

          In GitSCM, there is a method guessBrowser() that is capable of inferring the repository browser(with the help of regex using the url ). It has also been used in GitSCMBrowserTest.

          Can that be used for our purpose?

          Gyanesha Prajjwal added a comment - - edited In GitSCM, there is a method guessBrowser() that is capable of inferring the repository browser(with the help of regex using the url ). It has also been used in GitSCMBrowserTest. Can that be used for our purpose?

          Mark Waite added a comment -

          The guessBrowser() method is adequate for the current implementation but would need to be extended to fit with the idea that was suggested by Stephen Connolly. The guessBrowser() method is not part of an extension point, so other plugins cannot register their own implementations. Thus, the Gitea plugin (today) is not allowed to provide its own repository browser implementation which would appear with other repository browser choices.

          The guessBrowser() implementation could iterate over the implementations of an extension point, asking each implementation if it would like to provide a repository browser for the current repository URL.

          The Jenkins concept of an extension point allows one plugin (Git plugin in this case) to provide a location which other plugins may implement to provide a repository browser.

          Mark Waite added a comment - The guessBrowser() method is adequate for the current implementation but would need to be extended to fit with the idea that was suggested by Stephen Connolly. The guessBrowser() method is not part of an extension point, so other plugins cannot register their own implementations. Thus, the Gitea plugin (today) is not allowed to provide its own repository browser implementation which would appear with other repository browser choices. The guessBrowser() implementation could iterate over the implementations of an extension point, asking each implementation if it would like to provide a repository browser for the current repository URL. The Jenkins concept of an extension point allows one plugin (Git plugin in this case) to provide a location which other plugins may implement to provide a repository browser.

          Gyanesha Prajjwal added a comment - - edited

          What should be features of the extension point which will be created ( apart from inferring the browser ) ?  Will it be like one of those in hudson.plugins.git.extensions.impl ?

          Gyanesha Prajjwal added a comment - - edited What should be features of the extension point which will be created ( apart from inferring the browser ) ?  Will it be like one of those in hudson.plugins.git.extensions.impl ?

          Mark Waite added a comment -

          I assume that the extension point would need a method that would be passed the repository URL and would either return an instance of GitRepositoryBrowser or null. The null return would mean that the extension rejected the request to provide a browser, while if the GitRepositoryBrowser was returned, then that would be the inferred browser.

          Word of warning: I'm inexperienced in this part of the Jenkins ecosystem, so we may need to discuss it with others that are more experienced. fcojfernandez and rsandell do you have other guidance to offer?

          Mark Waite added a comment - I assume that the extension point would need a method that would be passed the repository URL and would either return an instance of GitRepositoryBrowser or null. The null return would mean that the extension rejected the request to provide a browser, while if the GitRepositoryBrowser was returned, then that would be the inferred browser. Word of warning: I'm inexperienced in this part of the Jenkins ecosystem, so we may need to discuss it with others that are more experienced. fcojfernandez and rsandell do you have other guidance to offer?

          Sorry, even I am new to this and I can't suggest anyone here. But I would love to contribute to this part of Jenkins. 

          Gyanesha Prajjwal added a comment - Sorry, even I am new to this and I can't suggest anyone here. But I would love to contribute to this part of Jenkins. 

          Sir, I have made a pull request by adding only an extension point for inferring browser. I haven't made any additional changes. Kindly look into this and suggest the required changes and other steps which I need to take.

          Gyanesha Prajjwal added a comment - Sir, I have made a pull request by adding only an extension point for inferring browser. I haven't made any additional changes. Kindly look into this and suggest the required changes and other steps which I need to take.

          Hrushi20 added a comment - - edited

          Hey! Can I get an overview regarding the this issue. I don't understand what is an extension point? I realized that the browser is already being detected by Jenkins using the auto mode. So what should be the final output at the end of solving this issue?

           

          Hrushi20 added a comment - - edited Hey! Can I get an overview regarding the this issue. I don't understand what is an extension point? I realized that the browser is already being detected by Jenkins using the auto mode. So what should be the final output at the end of solving this issue?  

          Kalle Niemitalo added a comment - hrushi20 , please see https://www.jenkins.io/doc/developer/extensibility/ and https://javadoc.jenkins-ci.org/hudson/Extension.html for information about extension points.

          Hrushi20 added a comment - - edited

          I created the an Extension implementing the Extension point. This extension contains the method which takes in a string and returns the GitRepositoryBrowser object. How do I register this extension with the GitSCM?

          Hrushi20 added a comment - - edited I created the an Extension implementing the Extension point. This extension contains the method which takes in a string and returns the GitRepositoryBrowser object. How do I register this extension with the GitSCM?

          Make the Git plugin call Jenkins.getExtensionList (javadoc) and ask each extension in the ExtensionList to infer the browser, until one of them succeeds or all of them have been tried.

          Kalle Niemitalo added a comment - Make the Git plugin call Jenkins.getExtensionList ( javadoc ) and ask each extension in the ExtensionList to infer the browser, until one of them succeeds or all of them have been tried.

          Hrushi20 added a comment -

          Thanks. I'll try that. Also I created a pull request where I created the extension.
          https://github.com/jenkinsci/git-plugin/pull/1251

          Hrushi20 added a comment - Thanks. I'll try that. Also I created a pull request where I created the extension. https://github.com/jenkinsci/git-plugin/pull/1251

          Hrushi20 added a comment -

          `Jenkins.getExtensionList` is not a static method. However, there is a method `Jenkins.get().getExtensionList()` which is used to get the desired Extension.

          Hrushi20 added a comment - `Jenkins.getExtensionList` is not a static method. However, there is a method `Jenkins.get().getExtensionList()` which is used to get the desired Extension.

          HelloWorld added a comment -

          Hello , I kindly ask to work on this issue .
          Here is how Iam going to approach the issue :please correct me
          1- Modify the constructor in GitSCM Class to infer the browser URL if none is provided and the repository URL is from a well-known host.
          2-Implement the inference logic as an ExtensionPoint.
          3- Modify GitStep Class to log the inference.

          HelloWorld added a comment - Hello , I kindly ask to work on this issue . Here is how Iam going to approach the issue :please correct me 1- Modify the constructor in GitSCM Class to infer the browser URL if none is provided and the repository URL is from a well-known host. 2-Implement the inference logic as an ExtensionPoint. 3- Modify GitStep Class  to log the inference.

          Mark Waite added a comment -

          sirine707 based on the past experiences of others, I suggest that you choose another issue. Implementing an extension point is not well-suited to a new contributor.

          Mark Waite added a comment - sirine707 based on the past experiences of others, I suggest that you choose another issue. Implementing an extension point is not well-suited to a new contributor.

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

              Created:
              Updated: