I have a Jenkins pipeline running two tests in parallel on two nodes, something like:

pipeline
{
    agent { label 'MASTER' }

    stages
    {
        stage('x86 and Arm tests')
        {
            parallel
            {
                stage('x86')
                {
                    agent
                    {
                        label ('x86')
                    }
                    steps
                    {
                        sh "something"
                    }
                }
                stage('arm')
                {
                    agent
                    {
                        label ('arm')
                    }
                    steps
                    {
                        sh "something"
                    }
                }
            }
        }
    }
}

The problem are the GitHub credentials: I need to have two different GitHub credentials for the two tests (x86 machine vs Arm machine).

Currently I have configured my job to authenticate via SSH key for the x86 machine. But this key seems not to work for Arm job.

How do I tell the Jenkins pipeline to use specific GitHub clone/checkout credentials within the stage?

Handling credentials.

CodePudding user response：

When running a declarative pipeline from SCM, for each agent that is used during the execution the repository used for loading the pipeline will be automatically checked out to the workspace.
If you want to change this default behavior and manually control the SCM configuration for each agent you must first disable that behavior using the skipDefaultCheckout option.

skipDefaultCheckout
Skip checking out code from source control by default in the agent directive.
For example: options { skipDefaultCheckout() }

Then in each agent you should check out your repository using your required parameters like branch, repository URL and credentials. For that you can use the generic checkout step or you can use other SCM specific steps like the git step which is a simplified shorthand for a subset of the more powerful checkout step.
If, on one of the agents, you want to use the same configuration used for fetching the pipeline script (like the default behavior) you can do so by using checkout scm.
Here is an example with several options:

pipeline {
    agent any
    options {
       skipDefaultCheckout()
    }
    stages {
        stage('Tests') {
            parallel {
                stage('x86') {
                    agent {
                        label 'x86'
                    }
                    steps {
                       // use the same configuration used for fetching the pipeline itself
                       checkout scm
                    }
                }
                stage('arm') {
                    agent {
                        label 'arm'
                    }
                    steps {
                        // use the checkout step - in this case for Git SCM
                        checkout([$class: 'GitSCM', branches: [[name: '*/master']],
                            userRemoteConfigs: [[credentialsId: 'my-private-key-credential-id', url: 'http://git-server/user/repository.git']]])
                    }
                }
                stage('x64') {
                    agent {
                        label 'x64'
                    }
                    steps {
                        // use the shortened git step
                        git branch: 'master', credentialsId: 'my-private-key-credential-id', url: 'https://github.com/jenkinsci/jenkins.git'
                    }
                }
            }
        }
    }
}

You now have the option to define different credentials on each build agent, and they will be used during the checkout process. Another alternative is to use the credentialsId option that the SCM steps have, define the credentials need for the SCM provider in Jenkins (username and password or ssh key) and pass them to the step - that way you do not need any pre-configuration on the agent.
See Using Credentials in Jenkins for more info.

In addition all the parameters that are passed to the SCM steps (branch, url, credentialsId, etc.) can be define as Job parameters - allowing you more flexibility and easy execution of different configurations.