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

Display Organization/Project and Repository name(s) on the job details page

      Currently when checking out multiple repositories or a single repository with submodules the Git plugin only displays the commit sha(s) and branch name(s) for each of the repositories being checked out on the job details page and as part of the Git Build Data.

      It would be useful to have the Organization/Project and Repository name(s) displayed alongside the commit sha(s) and branch name(s). This makes it easier to associate the changes to the repository.

          [JENKINS-54868] Display Organization/Project and Repository name(s) on the job details page

          Hrushi20 added a comment - - edited

          I got the global configuration page.

          I'll create an input tag which takes in the regex and then parses the url of the repository and display the Org Name/Repo name. The implementation can be tweaked based on the requirements.

          I am referring this link for configuring jelly with jenkins.

          Thank You

           

          Hrushi20 added a comment - - edited I got the global configuration page. I'll create an input tag which takes in the regex and then parses the url of the repository and display the Org Name/Repo name. The implementation can be tweaked based on the requirements. I am referring this link for configuring jelly with jenkins. Thank You  

          Ian Williams added a comment - - edited

          I'm a little confused about the intent of this JIRA, so just hoping to get clarity and validate requirements, given the ubiquitous utilization of the git plugin. I also don't pretend to be an expert on Git, the git-plugin, nor regex.

          PRESENT STATE: Status page and Git Build Data page show only the commit ref and the branch name.

          Git supports a variety of connection types/protocols (git:, http(s):, ssh:, ftp(s):, file: ), and the path/to/repo may take various forms.

          DESIRED STATE: Show the OrgName/RepoName. Or, given the nuances to come, [path/to/repo/]<repo_name>, or repo_url minus host_url;
          This would be equivalent to the Jenkins JOB_URL, minus the JENKINS_URL, call it the REPO_FULLNAME with the GITHOST_URL removed.

          I'd be interested in seeing the REPO_FULLNAME as just one of our instances connects to over 600 different repos on a variety of hosts.

          I often find to click configure to get validate the repo (and get the link to navigate), but at least seeing the repo name would cut significant toil.
          I am undecided whether an option to also show the GITHOST_NAME (not the GITHOST_URL) would be necessary to disambiguate.

          Our hosts include GitHub, Gitlab, AzureDevOps Server/TFS (on-prem), Gogs some just file://, (markewaite has listed more (above), like Assembla and BitBucket). Azure DevOps Server nomenclature is actually:
          http://tfs.mycorp.com/tfs/<TeamCollection>/<TeamProject>/_git/<RepoName>, so it's more than just <OrgName>/<Reponame>.
          Some of our host servers end in an internal domain which is not (com|org), We also don't need to supply a FQDN either; HOST will suffice.

          Thus the solution is more akin to: how to remove the HOST_URL given the wide variety of possible connection formats, not exclusively extract <OrgName>/<RepoName>.

          Assume the displayed REPO_FULLNAME would exclude any ".git" extension and in the case of AzureDevOps,, the "/_git" separator.

          The solution should be able to handle multiple GITHOST_URL for a given instance.
          It should be able to handle all the scenarios described, plus any nuances other host applications might throw.
          As admin, I also really don't want to have to maintain a regex property list for the users.

          Not a regex expert, but this regex ".(:[^/]|@|\/\/)([^/])\/"works to match the leading GITHOST_URL portion for the examples Mark provided, except for the one without a Assembla one without slash (git@git.assembla.com:git-plugin.bin.git).

          Any regex that strips the ending ".git" should not exclude a reponame ending in git (ie: https://github.com/git/git.git}}) or with git in the name (eg: https://github.com/git/git.github.io.git ) or other oddballs (eg: https://github.com/git/git-scm.com.git or http://tfs.mycorp.com/tfs/Collection/TeamProj/_git/automation_git; ). It should also properly handle the "/_git" or "/_ssh" MS throws at you.

          Not 100% sure this helps add clarity or validate the requirements, but I hope it at least identified some gotchas.

          (Removed clickable link remarks; seems it's a bad config / old instance my part).

          Ian Williams added a comment - - edited I'm a little confused about the intent of this JIRA, so just hoping to get clarity and validate requirements, given the ubiquitous utilization of the git plugin. I also don't pretend to be an expert on Git, the git-plugin, nor regex. PRESENT STATE: Status page and Git Build Data page show only the commit ref and the branch name. Git supports a variety of connection types/protocols (git:, http(s):, ssh:, ftp(s):, file: ), and the path/to/repo may take various forms. DESIRED STATE: Show the OrgName/RepoName . Or, given the nuances to come, [path/to/repo/] <repo_name> , or repo_url minus host_url; This would be equivalent to the Jenkins JOB_URL, minus the JENKINS_URL, call it the REPO_FULLNAME with the GITHOST_URL removed. I'd be interested in seeing the REPO_FULLNAME as just one of our instances connects to over 600 different repos on a variety of hosts. I often find to click configure to get validate the repo (and get the link to navigate), but at least seeing the repo name would cut significant toil. I am undecided whether an option to also show the GITHOST_NAME (not the GITHOST_URL) would be necessary to disambiguate. Our hosts include GitHub , Gitlab , AzureDevOps Server/TFS (on-prem), Gogs some just file:// , ( markewaite has listed more (above), like Assembla and BitBucket). Azure DevOps Server nomenclature is actually: http://tfs.mycorp.com/tfs/ <TeamCollection>/<TeamProject>/_git/<RepoName> , so it's more than just <OrgName>/<Reponame>. Some of our host servers end in an internal domain which is not (com|org), We also don't need to supply a FQDN either; HOST will suffice. Thus the solution is more akin to: how to remove the HOST_URL given the wide variety of possible connection formats, not exclusively extract <OrgName>/<RepoName>. Assume the displayed REPO_FULLNAME would exclude any ".git" extension and in the case of AzureDevOps,, the "/_git" separator. The solution should be able to handle multiple GITHOST_URL for a given instance. It should be able to handle all the scenarios described, plus any nuances other host applications might throw. As admin, I also really don't want to have to maintain a regex property list for the users. Not a regex expert, but this regex " . (: [^/] |@|\/\/)( [^/] )\/ "works to match the leading GITHOST_URL portion for the examples Mark provided, except for the one without a Assembla one without slash (git@git.assembla.com:git-plugin.bin.git). Any regex that strips the ending " .git " should not exclude a reponame ending in git (ie: https://github.com/git/git.git }}) or with git in the name (eg: https://github.com/git/git.github.io.git ) or other oddballs (eg: https://github.com/git/git-scm.com.git or http://tfs.mycorp.com/tfs/Collection/TeamProj/_git/automation_git ; ). It should also properly handle the "/_git" or "/_ssh" MS throws at you. Not 100% sure this helps add clarity or validate the requirements, but I hope it at least identified some gotchas. (Removed clickable link remarks; seems it's a bad config / old instance my part).

          PRESENT STATE: Status page and Git Build Data page show only the commit ref and the branch name.

          The repository URL was added to src/main/resources/hudson/plugins/git/util/BuildData/summary.jelly in JENKINS-38676 PR #1067. That was released in Git plugin 4.7.2 in June 2021.

          Is this issue a request to replace the full URL with the Organization/Project and Repository names only? If so, I think it should be opt-in.

          Kalle Niemitalo added a comment - PRESENT STATE: Status page and Git Build Data page show only the commit ref and the branch name. The repository URL was added to src/main/resources/hudson/plugins/git/util/BuildData/summary.jelly in JENKINS-38676 PR #1067 . That was released in Git plugin 4.7.2 in June 2021. Is this issue a request to replace the full URL with the Organization/Project and Repository names only? If so, I think it should be opt-in.

          Hrushi20 added a comment -

          Hey I have submitted a pull request. This is a basic version on which we can add the required features. We can discuss about the further implementation of the feature.

          https://github.com/jenkinsci/git-plugin/pull/1226

          Thank You

          Hrushi20 added a comment - Hey I have submitted a pull request. This is a basic version on which we can add the required features. We can discuss about the further implementation of the feature. https://github.com/jenkinsci/git-plugin/pull/1226 Thank You

          Hrushi20 added a comment -

          Hey! I have a doubt regarding testing. I created a global regex input field on the website. While testing, how do I create a global regex input and add it to the global configuration so that I can use it to get the organization name and repo name.

           

          Hrushi20 added a comment - Hey! I have a doubt regarding testing. I created a global regex input field on the website. While testing, how do I create a global regex input and add it to the global configuration so that I can use it to get the organization name and repo name.  

          Ian Williams added a comment - - edited

          As the objective of this feature is to display the OrgName/RepoName on the Job Build Log page, you'd have to create a set of dummy build logs that reflect all the possible combinations of legitimate Git connection types/protocols (git:, http(s):, ssh:, ftp(s):, file: ), to the various Git remote host types, both without an the permutations of supported Org structures, including things like a plain file: or plain remote connection, with and without password or token, etc. (pay attention to Azure Devops format which uses an unconventional format, with "/_git" ). Then test cases will validate the configured regex produce the expected results.

          Your requirements should be able to be validated passing a known set of inputs like Mark Waite listed and I added to. Segmented test cases should validate each configuration target type separately for the various connection options, or otherwise partitioned.

          One interesting feature is used in the REST List Parameter plugin and Build Failure Analyzer. Both plugins support a Test validation option as part of the configuration.

          Ian Williams added a comment - - edited As the objective of this feature is to display the OrgName/RepoName on the Job Build Log page, you'd have to create a set of dummy build logs that reflect all the possible combinations of legitimate Git connection types/protocols (git:, http(s):, ssh:, ftp(s):, file: ), to the various Git remote host types, both without an the permutations of supported Org structures, including things like a plain file: or plain remote connection, with and without password or token, etc. (pay attention to Azure Devops format which uses an unconventional format, with "/_git" ). Then test cases will validate the configured regex produce the expected results. Your requirements should be able to be validated passing a known set of inputs like Mark Waite listed and I added to. Segmented test cases should validate each configuration target type separately for the various connection options, or otherwise partitioned. One interesting feature is used in the REST List Parameter plugin and Build Failure Analyzer . Both plugins support a Test validation option as part of the configuration.

          Hrushi20 added a comment - - edited

          ianw , can you go through my draft pull request. Not sure how to create dummy build logs. I am actually new to testing and finding some difficulties. I feel the way I implemented the Global configuration is not correct. The global configuration regex takes in a single input regex and validates all the urls according to my implementation. Is the global configuration regex only for custom domains? Also Internally do I need to create a regex for default git urls.

           

          Pull request: link

          Hrushi20 added a comment - - edited ianw , can you go through my draft pull request. Not sure how to create dummy build logs. I am actually new to testing and finding some difficulties. I feel the way I implemented the Global configuration is not correct. The global configuration regex takes in a single input regex and validates all the urls according to my implementation. Is the global configuration regex only for custom domains? Also Internally do I need to create a regex for default git urls.   Pull request: link

          Kris Stern added a comment -

          hrushi20, would just like to chip in and say that the implementation can vary depending on your conception of it and how it will be implemented. It could be either a list of URL regex patterns or a single URL regex pattern. However, if you are aiming to use one single URL regex pattern than be aware that this might be harder to maintain and use down the line. Other factors to consider would be customisability and usability as a global option as suggested above. 

          Kris Stern added a comment - hrushi20 , would just like to chip in and say that the implementation can vary depending on your conception of it and how it will be implemented. It could be either a list of URL regex patterns or a single URL regex pattern. However, if you are aiming to use one single URL regex pattern than be aware that this might be harder to maintain and use down the line. Other factors to consider would be customisability and usability as a global option as suggested above. 

          Kris Stern added a comment -

          For testing maybe the list of example URLs could be checked one by one for assertion to be `true`. You will need to at least test the organisation and project repo in two separate tests for example. If you are testing a list of possible URL regex patterns, be sure to classify the URLs accordingly and write a test for each category. It is up to you to propose a viable solution, so we are only making suggestions to you. You have the freedom to decide ultimately how you would like to approach the problem. 

          Kris Stern added a comment - For testing maybe the list of example URLs could be checked one by one for assertion to be `true`. You will need to at least test the organisation and project repo in two separate tests for example. If you are testing a list of possible URL regex patterns, be sure to classify the URLs accordingly and write a test for each category. It is up to you to propose a viable solution, so we are only making suggestions to you. You have the freedom to decide ultimately how you would like to approach the problem. 

          Hrushi20 added a comment -

          Multiple Regex can be added in the global configuration. Each regex needs to be separated by `&&&` for now. All urls stated by markewaite are running successfully. Looking for edge cases to solve. I'll try adding more test cases related to azure and other protocols.

          Hrushi20 added a comment - Multiple Regex can be added in the global configuration. Each regex needs to be separated by `&&&` for now. All urls stated by markewaite are running successfully. Looking for edge cases to solve. I'll try adding more test cases related to azure and other protocols.

            Unassigned Unassigned
            tarungidwani Tarun Gidwani
            Votes:
            9 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated: