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

GitSCMSource: support custom remote and refspec

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      Allow to set custom remote name and refspec in the advanced options of a
      git source. Can be useful for example in the Pipeline: multibranch plugin to fetch merge/pull requests usually available under a different namespace (eg on Github/Gitlab).

        Attachments

          Activity

          jbq jbq created issue -
          markewaite Mark Waite made changes -
          Field Original Value New Value
          Assignee Mark Waite [ markewaite ]
          Hide
          markewaite Mark Waite added a comment -

          Could you provide more details of the use case(s) where you think this would be useful?

          Show
          markewaite Mark Waite added a comment - Could you provide more details of the use case(s) where you think this would be useful?
          jbq jbq made changes -
          Description Allow to set custom remote name and refspec in the advanced options of a
          git source
          Allow to set custom remote name and refspec in the advanced options of a
          git source. Can be useful for example in the Pipeline: multibranch plugin to fetch merge/pull requests usually available under a different namespace (eg on Github/Gitlab).
          Hide
          jbq jbq added a comment -

          Added in the description: can be useful for example in the Pipeline: multibranch plugin to fetch merge/pull requests usually available under a different namespace (eg on Github/Gitlab).

          Show
          jbq jbq added a comment - Added in the description: can be useful for example in the Pipeline: multibranch plugin to fetch merge/pull requests usually available under a different namespace (eg on Github/Gitlab).
          Hide
          jbq jbq added a comment -

          Would you mind considering this? Pull request available.

          Show
          jbq jbq added a comment - Would you mind considering this? Pull request available.
          jbq jbq made changes -
          Assignee Stephen Connolly [ stephenconnolly ]
          Hide
          abhay abhay chrungoo added a comment -

          +1
          Usecase: would allow multibranch pipeline to work with gerrit patchsets . Currently there isnt another alternative available for gerrit patchsets.

          eg:
          +refs/changes/:refs/remotes/origin/patchset/

          Show
          abhay abhay chrungoo added a comment - +1 Usecase: would allow multibranch pipeline to work with gerrit patchsets . Currently there isnt another alternative available for gerrit patchsets. eg: +refs/changes/ :refs/remotes/origin/patchset/
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Jean-Baptiste Quenot
          Path:
          src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java
          src/main/java/jenkins/plugins/git/GitSCMSource.java
          src/main/resources/jenkins/plugins/git/GitSCMSource/config-detail.jelly
          src/test/java/jenkins/plugins/git/AbstractGitSCMSourceTest.java
          http://jenkins-ci.org/commit/git-plugin/c7809b55c42532afd13d5587076c9cf437167fe3
          Log:
          Merge pull request #466 from jbq/git_source_advanced_options

          JENKINS-40908 GitSCMSource: support custom remote and refspec

          Compare: https://github.com/jenkinsci/git-plugin/compare/d2c36cf91698...c7809b55c425

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jean-Baptiste Quenot Path: src/main/java/jenkins/plugins/git/AbstractGitSCMSource.java src/main/java/jenkins/plugins/git/GitSCMSource.java src/main/resources/jenkins/plugins/git/GitSCMSource/config-detail.jelly src/test/java/jenkins/plugins/git/AbstractGitSCMSourceTest.java http://jenkins-ci.org/commit/git-plugin/c7809b55c42532afd13d5587076c9cf437167fe3 Log: Merge pull request #466 from jbq/git_source_advanced_options JENKINS-40908 GitSCMSource: support custom remote and refspec Compare: https://github.com/jenkinsci/git-plugin/compare/d2c36cf91698...c7809b55c425
          Hide
          jbq jbq added a comment -

          Merged the PR myself after successfully running all tests locally

          Show
          jbq jbq added a comment - Merged the PR myself after successfully running all tests locally
          jbq jbq made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Assignee Stephen Connolly [ stephenconnolly ] jbq [ jbq ]
          Resolution Fixed [ 1 ]
          Hide
          markewaite Mark Waite added a comment -

          I'm headed to a funeral out of state currently, so won't have time to express the details of my concern at your decision to merge the PR yourself without allowing time for the maintainer to validate it.

          Could you please discuss the situation with Daniel Beck and R. Tyler Croy? I'd like you to confirm that your merging the pull request yourself is within the bounds of the community guidelines. I'm fine with that if it is, and I don't have time to review the community guidelines in detail to decide.

          It hasn't been a general practice that people I don't recognize have merged changes to the master branch of the git plugin or the git client plugin.

          Show
          markewaite Mark Waite added a comment - I'm headed to a funeral out of state currently, so won't have time to express the details of my concern at your decision to merge the PR yourself without allowing time for the maintainer to validate it. Could you please discuss the situation with Daniel Beck and R. Tyler Croy ? I'd like you to confirm that your merging the pull request yourself is within the bounds of the community guidelines. I'm fine with that if it is, and I don't have time to review the community guidelines in detail to decide. It hasn't been a general practice that people I don't recognize have merged changes to the master branch of the git plugin or the git client plugin.
          Hide
          jbq jbq added a comment -

          Hi Mark! Sorry to learn that my decision to merge the PR myself has been taken as an offense. In fact I'm a committer of the git plugin of the early days, that's why I have commit rights on this repo. However if you think this is inappropriate and against new guidelines that I am maybe not aware of, feel free to revert the commit and remove me from the committers. My only wish is that the proposed change be reviewed and eventually incorporated into Jenkins. I also noticed that the PR has been upvoted 11 times so I may not be the only one.

          Thanks for your understanding!

          Show
          jbq jbq added a comment - Hi Mark! Sorry to learn that my decision to merge the PR myself has been taken as an offense. In fact I'm a committer of the git plugin of the early days, that's why I have commit rights on this repo. However if you think this is inappropriate and against new guidelines that I am maybe not aware of, feel free to revert the commit and remove me from the committers. My only wish is that the proposed change be reviewed and eventually incorporated into Jenkins. I also noticed that the PR has been upvoted 11 times so I may not be the only one. Thanks for your understanding!
          Hide
          markewaite Mark Waite added a comment -

          No offense was taken from your decision to merge the pull request. I don't see any need to remove you from the committers or anything drastic like that.

          I was very pleased to see all the upvotes, since that shows people were thinking about the pull request. I didn't recognize any of the users who were upvoting the pull request, nor did I see any comments that any of the upvotes had tested the proposed pull request, so I wasn't sure how much credence I should place on those upvotes.

          Are you interested in assisting further with review of git plugin pull requests?

          Show
          markewaite Mark Waite added a comment - No offense was taken from your decision to merge the pull request. I don't see any need to remove you from the committers or anything drastic like that. I was very pleased to see all the upvotes, since that shows people were thinking about the pull request. I didn't recognize any of the users who were upvoting the pull request, nor did I see any comments that any of the upvotes had tested the proposed pull request, so I wasn't sure how much credence I should place on those upvotes. Are you interested in assisting further with review of git plugin pull requests?
          Hide
          jbq jbq added a comment -

          Hi Mark, it looks like I'm forgiven. Great! I'd be happy to assist in reviewing the issues and pull requests. With great pleasure! It's good to be back to Jenkins business!

          Best regards, JB Quenot

          Show
          jbq jbq added a comment - Hi Mark, it looks like I'm forgiven. Great! I'd be happy to assist in reviewing the issues and pull requests. With great pleasure! It's good to be back to Jenkins business! Best regards, JB Quenot
          Hide
          markewaite Mark Waite added a comment - - edited

          I'd love to have more help evaluating pull requests. Choose pull requests that you think are interesting to the community and to you.

          I evaluate pull requests by

          1. Confirm that I can see the problem described in the pull request (before any change from the pull request) - I've generally preferred to show the problem as a job definition in the lts-with-plugins branch of my jenkins docker image so that I can then continue to reuse that job definition in later regression tests
          2. Merge the pull request onto a branch on my fork which starts with the current master branch (merge instructions are included in the pull request automatically behind a link)
          3. Build the pull request, run its automated tests, and install it into the docker instance where I've verified the problem is visible
          4. Run the job which showed the problem and confirm that the problem is now resolved
          5. Run other jobs in that test instance to confirm that none of them regressed from the changes, investigate and correct detected failures
          6. Review the code changes - reject API incopmatibilities, ask for corrections to changes which are purely white space, etc.
          7. Review the test changes - confirm that there are tests and that they test the expected conditions
          8. Evaluate if this change needs to be included on the "old" branch (git plugin 2.6.x and git client plugin 1.21.x) - prefer to not include changes on the old branch, since the old branch lacks submodule authentication support and only exists in those cases where a user cannot tolerate the submodule authentication related changes

          In order to reduce duplication of effort, it might be good to record in the pull request comments that you've started evaluating the pull request. I'll do the same for pull requests that I'm evaluating.

          Show
          markewaite Mark Waite added a comment - - edited I'd love to have more help evaluating pull requests. Choose pull requests that you think are interesting to the community and to you. I evaluate pull requests by Confirm that I can see the problem described in the pull request (before any change from the pull request) - I've generally preferred to show the problem as a job definition in the lts-with-plugins branch of my jenkins docker image so that I can then continue to reuse that job definition in later regression tests Merge the pull request onto a branch on my fork which starts with the current master branch (merge instructions are included in the pull request automatically behind a link) Build the pull request, run its automated tests, and install it into the docker instance where I've verified the problem is visible Run the job which showed the problem and confirm that the problem is now resolved Run other jobs in that test instance to confirm that none of them regressed from the changes, investigate and correct detected failures Review the code changes - reject API incopmatibilities, ask for corrections to changes which are purely white space, etc. Review the test changes - confirm that there are tests and that they test the expected conditions Evaluate if this change needs to be included on the "old" branch (git plugin 2.6.x and git client plugin 1.21.x) - prefer to not include changes on the old branch, since the old branch lacks submodule authentication support and only exists in those cases where a user cannot tolerate the submodule authentication related changes In order to reduce duplication of effort, it might be good to record in the pull request comments that you've started evaluating the pull request. I'll do the same for pull requests that I'm evaluating.
          Hide
          markewaite Mark Waite added a comment -

          Included in git plugin 3.1.0 released 4 Mar 2017

          Show
          markewaite Mark Waite added a comment - Included in git plugin 3.1.0 released 4 Mar 2017
          markewaite Mark Waite made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              jbq jbq
              Reporter:
              jbq jbq
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: