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

Pipeline step to run Git commands with credentials & tool

    XMLWordPrintable

    Details

    • Similar Issues:
    • Released As:
      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

            Hide
            llibicpep Dee Kryvenko added a comment -

            New gitUsernamePassword binding only accounts for a single set of credentials.

            Often there are different set of credentials required for different git locations.

            Examples would be Go Modules, Terraform Modules and other that are using Git for dependency management. If the current repository we are building have dependencies on other repositories - we need read-write git credentials to the current repository (so we could publish tags, for example) while we need read-only set of credentials to everything else for fetching dependencies.

            If this binding currently implemented as AskPass helper - an easy fix would be to accept additional parameter in the binding that'd tell the location the binding is for.

            Show
            llibicpep Dee Kryvenko added a comment - New gitUsernamePassword binding only accounts for a single set of credentials. Often there are different set of credentials required for different git locations. Examples would be Go Modules, Terraform Modules and other that are using Git for dependency management. If the current repository we are building have dependencies on other repositories - we need read-write git credentials to the current repository (so we could publish tags, for example) while we need read-only set of credentials to everything else for fetching dependencies. If this binding currently implemented as AskPass helper - an easy fix would be to accept additional parameter in the binding that'd tell the location the binding is for.
            Hide
            markewaite Mark Waite added a comment -

            Dee Kryvenko 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.

            Show
            markewaite Mark Waite added a comment - Dee Kryvenko 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.
            Hide
            llibicpep Dee Kryvenko added a comment -

            Mark Waite - 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).

            Show
            llibicpep Dee Kryvenko added a comment - Mark Waite - 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).
            Hide
            markewaite Mark Waite added a comment -

            Dee Kryvenko 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.

            Show
            markewaite Mark Waite added a comment - Dee Kryvenko 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.
            Hide
            llibicpep Dee Kryvenko added a comment - - edited

            Mark Waite 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.

            Show
            llibicpep Dee Kryvenko added a comment - - edited Mark Waite 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.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              alecharp Adrien Lecharpentier
              Votes:
              150 Vote for this issue
              Watchers:
              157 Start watching this issue

                Dates

                Created:
                Updated: