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

Pipeline step to run Git commands with credentials & tool

    XMLWordPrintable

Details

    • 4.8.0 - released username / password credential binding

    Description

      It would be nice to be able to use the GitPublisher inside a workflow as it is possible in other jobs.

      This requires the plugin to be upgrade to Jenkins core 1.580.1+, to implement the jenkins.tasks.SimpleBuildStep in GitPublisher

      Attachments

        Issue Links

          Activity

            markewaite Mark Waite added a comment -

            llibicpep couldn't you achieve the same result by having a single credential that is used for read access to all repositories and an additional credential that allows read/write access to the one repository that needs to be written? Read operations (like fetch and clone) would be performed inside a withCredentials block using the read credentials, then a separate withCredentials block would be used to perform the write operations.

            markewaite Mark Waite added a comment - llibicpep couldn't you achieve the same result by having a single credential that is used for read access to all repositories and an additional credential that allows read/write access to the one repository that needs to be written? Read operations (like fetch and clone) would be performed inside a withCredentials block using the read credentials, then a separate withCredentials block would be used to perform the write operations.
            llibicpep Dee Kryvenko added a comment -

            markewaite - you are assuming entire pipeline is a Jenkinsfile. That is far from being even in majority of the cases. In reality - Jenkinsfile delegates to the tools such as Make/Maven/Gradle/NPM/Terraform/etc. User-supplied untrusted code should be able to safely access only what's it allowed to - write to the current repository and read other repositories as dependencies. From the Jenkinsfile level - we don't have exposure into what is going to happen in the user-supplied code. To enable this workflow - we need to pass in to the tool several sets of credentials. And it might be even more complicated as there could be several locations such as GitHub Orgs in play with different sets of credentials each - or even entirely different providers (GitHub+GitLab for example).

            llibicpep Dee Kryvenko added a comment - markewaite - you are assuming entire pipeline is a Jenkinsfile. That is far from being even in majority of the cases. In reality - Jenkinsfile delegates to the tools such as Make/Maven/Gradle/NPM/Terraform/etc. User-supplied untrusted code should be able to safely access only what's it allowed to - write to the current repository and read other repositories as dependencies. From the Jenkinsfile level - we don't have exposure into what is going to happen in the user-supplied code. To enable this workflow - we need to pass in to the tool several sets of credentials. And it might be even more complicated as there could be several locations such as GitHub Orgs in play with different sets of credentials each - or even entirely different providers (GitHub+GitLab for example).
            markewaite Mark Waite added a comment -

            llibicpep since the withCredentials step provides the credential to all git operations inside the sh, bat, or powershell step, I would expect it to be well behaved whether the program that called git was make, maven, gradle, bazel, or any other tool. I think your scenario of mapping different credentials to individual repositories sounds like a more challenging use case than I'm ready to solve using the withCredentials technique.

            markewaite Mark Waite added a comment - llibicpep since the withCredentials step provides the credential to all git operations inside the sh , bat , or powershell step, I would expect it to be well behaved whether the program that called git was make, maven, gradle, bazel, or any other tool. I think your scenario of mapping different credentials to individual repositories sounds like a more challenging use case than I'm ready to solve using the withCredentials technique.
            llibicpep Dee Kryvenko added a comment - - edited

            markewaite the "program" might want to fetch dependencies AND push a release tag, as an example, all in the same time. You don't get to know that from your Jenkinsfile. In the Jenkinsfile it is a single step.

            It's all quite simple actually - the new bindings could accept multiple pairs url:credential-id which would render into a config file like this:

            [credential "https://github.com"]
            	useHttpPath = true
            	helper = ...
            [credential "https://gitlab.com"]
            	useHttpPath = true
            	helper = ...
            

            And the helper then would look into both host AND path in the input (which the latter would only be available when useHttpPath = true) to match with a UsernamePasswordCredentials instance.

            llibicpep Dee Kryvenko added a comment - - edited markewaite the "program" might want to fetch dependencies AND push a release tag, as an example, all in the same time. You don't get to know that from your Jenkinsfile. In the Jenkinsfile it is a single step. It's all quite simple actually - the new bindings could accept multiple pairs url:credential-id which would render into a config file like this: [credential "https: //github.com" ] useHttpPath = true helper = ... [credential "https: //gitlab.com" ] useHttpPath = true helper = ... And the helper then would look into both host AND path in the input (which the latter would only be available when useHttpPath = true ) to match with a UsernamePasswordCredentials instance.
            urld David Url added a comment -

            Would this feature work as well in stages that run in containers?

            urld David Url added a comment - Would this feature work as well in stages that run in containers?

            People

              Unassigned Unassigned
              alecharp Adrien Lecharpentier
              Votes:
              155 Vote for this issue
              Watchers:
              161 Start watching this issue

              Dates

                Created:
                Updated: