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

GitSCMSource: support custom remote and refspec

    XMLWordPrintable

    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

          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

            People

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

              Dates

              • Created:
                Updated:
                Resolved: