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

Add a withGit pipeline step that provides git credentials

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

      It would be nice if we had a withGit step that would pre-configure the git credentials from the current "scm" object and allows us to invoke git from the command line as follows:

      withGit {
         sh 'git fetch'
      }

      The step would rely on the same GIT_ASKPASS mechanism as used during a "standard" checkout.

       

        1. mktemp.groovy
          0.6 kB
        2. rmdir.groovy
          0.4 kB
        3. utils.groovy
          2 kB
        4. withGit.groovy
          3 kB

          [JENKINS-47733] Add a withGit pipeline step that provides git credentials

          Thomas Ramé added a comment -

          Hi brenuart, I'm also looking for the easiest way to pull dependencies in private repositories... For now how do you manage using credentials with Git inside a pipeline? Do you use withCredentials(...) function?

           

          Thank you.

          Thomas Ramé added a comment - Hi brenuart , I'm also looking for the easiest way to pull dependencies in private repositories... For now how do you manage using credentials with Git inside a pipeline? Do you use withCredentials(...) function?   Thank you.

          Yes, we implemented our own withGit step in our shared library - see attached file. Feel free to use it/comment if you like

           

          Bertrand Renuart added a comment - Yes, we implemented our own withGit step in our shared library - see attached file. Feel free to use it/comment if you like  

          Thomas Ramé added a comment -

          brenuart thank you very much! It seems a more appropriate way than trying to inject a SSH key with sshagent(...).

           

          There is still one question about reusing the credentials: imagine the user "Thomas" creates a pipeline within Jenkins with his GitHub credentials to access the repository, to build my project I need to pull X dependencies with some from private repositories. If the user "Thomas" doesn't have access to all these private repositories it will fail... That's the same if "Thomas" leaves the company, we should delete all his pipelines and recreate them, no? The workaround I think about is either to use SSH key able to access all private repositories (that's why I was trying to use sshagent(...) ), or to create a dedicated "Jenkins" user to create new pipeline. With a dedicated user I'm sure it will persist over time and that it has access to all private repositories. Which way did you choose?

          (For your information: I'm using Jenkins Blue Ocean)

           

          By the way I have an error, during the execution it cannot find "mktemp". Here is the error:

          "No such DSL method 'mktemp' found among steps"

           

          Do you have a specific "global" library that imports the right tool? Maybe you already had this issue...

           

          Thank you,

          Thomas Ramé added a comment - brenuart thank you very much! It seems a more appropriate way than trying to inject a SSH key with sshagent(...).   There is still one question about reusing the credentials: imagine the user "Thomas" creates a pipeline within Jenkins with his GitHub credentials to access the repository, to build my project I need to pull X dependencies with some from private repositories. If the user "Thomas" doesn't have access to all these private repositories it will fail... That's the same if "Thomas" leaves the company, we should delete all his pipelines and recreate them, no? The workaround I think about is either to use SSH key able to access all private repositories (that's why I was trying to use sshagent(...) ), or to create a dedicated "Jenkins" user to create new pipeline. With a dedicated user I'm sure it will persist over time and that it has access to all private repositories. Which way did you choose? (For your information: I'm using Jenkins Blue Ocean)   By the way I have an error, during the execution it cannot find "mktemp". Here is the error: "No such DSL method 'mktemp' found among steps"   Do you have a specific "global" library that imports the right tool? Maybe you already had this issue...   Thank you,

          We are using the same 'jenkins' user to access all repositories and other remote resources - so we don't have the problem you describe... Can't help you much on that subject - sorry.

          Concerning `mktemp` it comes indeed from our shared global libraries - see the attached file.

          Bertrand Renuart added a comment - We are using the same 'jenkins' user to access all repositories and other remote resources - so we don't have the problem you describe... Can't help you much on that subject - sorry. Concerning `mktemp` it comes indeed from our shared global libraries - see the attached file.

          Thomas Ramé added a comment -

          brenuart if you do not mind, could you also provide the "utils" Groovy script? I'm sorry it's triggering error one by one, I was thinking "utils" was included.

          I'm sure it will help some others  Unable to render embedded object: File ( Thanks) not found.

           

          Thomas Ramé added a comment - brenuart if you do not mind, could you also provide the "utils" Groovy script? I'm sorry it's triggering error one by one, I was thinking "utils" was included. I'm sure it will help some others   Unable to render embedded object: File ( Thanks) not found.  

          Thomas Ramé added a comment -

          brenuart I checked online the docs for Jenkins Pipeline and have found that I was able to replace your line:

                      if (utils.isUnixLike()) {
          

          by

                      if (isUnix()) {
          

          I'm still looking for an official way to delete the directory with an official manner since your "rmdir" is apparently also imported from your shared library ("No such DSL method 'rmdir' found among steps")

          Thomas Ramé added a comment - brenuart I checked online the docs for Jenkins Pipeline and have found that I was able to replace your line: if (utils.isUnixLike()) { by if (isUnix()) { I'm still looking for an official way to delete the directory with an official manner since your "rmdir" is apparently also imported from your shared library ("No such DSL method 'rmdir' found among steps")

          Additional files... If you are still missing stuff, email me and I'll send you a zip with everything... (don't want to use Jira here as a file exchange mechanism

          Bertrand Renuart added a comment - Additional files... If you are still missing stuff, email me and I'll send you a zip with everything... (don't want to use Jira here as a file exchange mechanism

          Thomas Ramé added a comment -

          It works like a charm! You made me saving time  ... Thank you!

           

          For anyone who is interested, don't hesitate to fork the following repo (I have wrapped required files into a library ready to be used in Jenkins):

          https://github.com/sneko/jenkins-git-shared

           

          Thomas Ramé added a comment - It works like a charm! You made me saving time  ... Thank you!   For anyone who is interested, don't hesitate to fork the following repo (I have wrapped required files into a library ready to be used in Jenkins): https://github.com/sneko/jenkins-git-shared  

          jerry wiltse added a comment -

          we created one also.
          damn i wish this existed to work around:
          https://issues.jenkins.io/browse/JENKINS-30600

          jerry wiltse added a comment - we created one also. damn i wish this existed to work around: https://issues.jenkins.io/browse/JENKINS-30600

          Mark Waite added a comment -

          Closing as a duplicate of JENKINS-28335. Refer to the Google Summer of Code project idea proposing how JENKINS-28335 should be implemented.

          The project idea needs additional mentors and welcomes additional insights on corner cases that might not be covered by the proposed implementation.

          Mark Waite added a comment - Closing as a duplicate of JENKINS-28335 . Refer to the Google Summer of Code project idea proposing how JENKINS-28335 should be implemented. The project idea needs additional mentors and welcomes additional insights on corner cases that might not be covered by the proposed implementation.

          Jesse Glick added a comment -

          markewaite while this is clearly related to JENKINS-28335, the current GSoC proposal would not offer a UX comparable to what was requested in this issue’s initial description.

          Jesse Glick added a comment - markewaite while this is clearly related to JENKINS-28335 , the current GSoC proposal would not offer a UX comparable to what was requested in this issue’s initial description.

          Mark Waite added a comment - - edited

          Thanks for the insight jglick. You're correct. I didn't read carefully enough. This issue proposes to use the credentials from the scm global variable while the GSoC proposal would require that the Pipeline must provide the credentials ID to be used in the Pipeline step. I've reopened this issue .

          Mark Waite added a comment - - edited Thanks for the insight jglick . You're correct. I didn't read carefully enough. This issue proposes to use the credentials from the scm global variable while the GSoC proposal would require that the Pipeline must provide the credentials ID to be used in the Pipeline step. I've reopened this issue .

          Bobs Ur Uncle added a comment -

          This gets most of the way there, albeit with more verbosity:

                          withCredentials([gitUsernamePassword(credentialsId: scm.getUserRemoteConfigs()[0].getCredentialsId())]) {
                              sh '''
                              git fetch
                              '''
                          } 

          Bobs Ur Uncle added a comment - This gets most of the way there, albeit with more verbosity: withCredentials([gitUsernamePassword(credentialsId: scm.getUserRemoteConfigs()[0].getCredentialsId())]) { sh ''' git fetch ''' }

          Jim Klimov added a comment -

          Thanks for the hint. This actually seems a bit safer than sticking a credential name into public Jenkisfiles (which someone else might try to abuse from their PR, etc.) Sure there are protections for PRs (who may change Jenkinsfile so its PRed code runs), folder-level credentials, etc. - but it is extra hassle and feels like an extra option for a security mistake.

          Jim Klimov added a comment - Thanks for the hint. This actually seems a bit safer than sticking a credential name into public Jenkisfiles (which someone else might try to abuse from their PR, etc.) Sure there are protections for PRs (who may change Jenkinsfile so its PRed code runs), folder-level credentials, etc. - but it is extra hassle and feels like an extra option for a security mistake.

            Unassigned Unassigned
            brenuart Bertrand Renuart
            Votes:
            9 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated: