0

When I execute my pipeline and I go and see on the actual Jenkins slave, the checked out commit doesn't have latest changes. But the logs and actual files in the workspace on the Jenkins slave running this build are confusing me.

In the logs Jenkins shows it is resolving commit id for the previous commit on the branch (notice the carrot at the end):

/usr/bin/git rev-parse refs/remotes/origin/BranchName^

but in a log line after this it shows a fetch command with correct latest commit id and latest commit message.

/usr/bin/git checkout -f 25d8dd262b61a8f703912db297kuhg76768 # timeout=10
Commit message: "Latest commit message"

I HAVE

always { 
            cleanWs()
        } 

in the post stage SO THIS IS NOT WORKSPACE CLEAN UP ISSUE. Workspace is getting cleaned after every build I checked it in logs and also on the server.

Other thing that I did is, when build was triggered I did SSH into the Jenkins slave machine where build was running and checked the files in actual workspace but the files were old and the head was is detached state pointing to the correct latest commit. As mentioned above the log was showing Jenkins executed git -f checkout . (Full log is provided below)

Why the git and checkout steps in the Jenkins pipeline take the code from the repository this way?

I want to understand why this plugin does all these steps in the log below, why can't it just clone new repo, pull a latest commit using reference and that's it.

I have following step in my declarative pipeline:

dir("${branch_name}/somedir"){
                    checkout(
                        [
                            $class: 'GitSCM', 
                            branches: [[name: 'refs/heads/${branch_name}']], 
                            doGenerateSubmoduleConfigurations: false, 
                            extensions: [], submoduleCfg: [], 
                            userRemoteConfigs: [
                                [
                                credentialsId: 'XXXXXX',
                                name: 'origin', 
                                refspec: '+refs/heads/${branch_name}:refs/remotes/origin/${branch_name}', 
                                url: 'https://github.com/xyz/repo.git'
                                ]
                            ]
                        ])
                }

And in the logs I see following:

    Cloning the remote Git repository
Cloning repository https://github.com/xyz/repo.git
 > /usr/bin/git init /pathToWorkspace/somedir # timeout=10
Fetching upstream changes from https://github.com/xyz/repo.git
 > /usr/bin/git --version # timeout=10
 > git --version # 'git version 2.23.4'
using GIT_ASKPASS to set credentials Used to pull the code from GitHub as JenkinsUser user
 > /usr/bin/git fetch --tags --force --progress -- https://github.com/xyz/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=10
Checking out Revision 25d8dd262b61a8f703912db297kuhg76768 (refs/remotes/origin/BranchName)
 > /usr/bin/git config remote.origin.url https://github.com/xyz/repo.git # timeout=10
 > /usr/bin/git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > /usr/bin/git config remote.origin.url https://github.com/xyz/repo.git # timeout=10
Fetching upstream changes from https://github.com/xyz/repo.git
using GIT_ASKPASS to set credentials Used to pull the code from GitHub as JenkinsUser user
 > /usr/bin/git fetch --tags --force --progress -- https://github.com/xyz/repo.git +refs/heads/BranchName:refs/remotes/origin/BranchName # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/BranchName^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/refs/heads/BranchName^{commit} # timeout=10
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 25d8dd262b61a8f703912db297kuhg76768 # timeout=10
Commit message: "Latest commit message"
 > /usr/bin/git rev-list --no-walk 25d8dd262b61a8f703912db297kuhg76768 # timeout=10
2
  • Set branches to [[name: branch_name]] and for userRemoteConfigs remove the name and refspec keys. Then re-run your build and see if it happens again.
    – Levi
    Aug 2 at 13:34
  • 1
    gitSCM logic. The git plugin also flips between git and jgit based on optimized performance
    – Ian W
    Aug 6 at 5:58

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.