-
Bug
-
Resolution: Not A Defect
-
Minor
-
OS Linux
Git is running as Docker container
Tested on versions:
Jenkins 2.164.1, git plugin 3.9.3
Jenkins 2.263.1 git plugin 4.5.1
Hello,
I doing clone outside of Jenkins into some shared folder using LSF workload management platform by IBM
Or let’s say I doing clone manually from command line
Then I want to pull changes and checkout branch using GIT plugin
It works, but takes same time as full clone. Means takes 5-7 minutes instead of 20 seconds
Can you explain this behavior, please ? How I can handle it ?
My local repository is completely functional. And I want to make checkout in 20 sec
Thank you
Code:
stage('checkout') { steps { script { node('linux4') { ws("/comm/data_10/some_folder") { // Git plugin will not pull submodules with --force option, // if there are local changes it fails the CI (JENKINS-27625, JENKINS-55875). sh "git submodule foreach --recursive git reset --hard || true" checkout([ $class: 'GitSCM', branches: [[name: "develop"]], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'CheckoutOption', timeout: 25 ], [$class: 'SubmoduleOption', disableSubmodules: false, parentCredentials: false, recursiveSubmodules: true, reference: '', trackingSubmodules: true]], userRemoteConfigs: [[credentialsId: env.CRED, url: env.REPO]] ]) } }} } }
Log (I added debug variable as hudson.plugins.git.GitSCM.verbose=true):
10:40:29 Using checkout strategy: Default 10:40:29 Last Built Revision: Revision 7588941db5123456975ff1234567ef8733f20b0b (origin/develop) 10:40:29 The recommended git tool is: NONE 10:40:29 using credential f76306ee-b3d1-4169-9582-123467 10:40:29 Fetching changes from the remote Git repository 10:40:28 > git rev-parse --is-inside-work-tree # timeout=10 10:40:28 > git config remote.origin.url <removed_remote_URL> # timeout=10 10:40:28 Fetching upstream changes from <removed_remote_URL> 10:40:28 > git --version # timeout=10 10:40:28 > git --version # 'git version 2.28.1' 10:40:28 using GIT_ASKPASS to set credentials SIRC DevOps 10:40:28 > git fetch --tags --progress -- git@gitlab-srv:CDE-Users/HW_ALG.git +refs/heads/*:refs/remotes/origin/* # timeout=10 10:40:31 getCandidateRevisions(false,develop,,,hudson.plugins.git.util.BuildData@18b394fa[scmName=<null>,remoteUrls=[<removed_remote_URL>],buildsByBranchName={origin/develop=Build #31 of Revision 7588941db57d8597975ff98bb3d7ef8733f20b0b (origin/develop)},lastBuild=Build #31 of Revision 7588941db57d8597975ff98bb3d7ef8733f20b0b (origin/develop)]) considering branches to build 10:40:31 Qualifying develop as a branch in repository origin -> origin/develop 10:40:31 rev-parse origin/develop -> AnyObjectId[7588941db5123456975ff1234567ef8733f20b0b] 10:40:31 Found a new commit AnyObjectId[7588941db5123456975ff1234567ef8733f20b0b] to be built on origin/develop 10:40:31 Checking out Revision 7588941db5123456975ff1234567ef8733f20b0b (origin/develop) 10:40:30 > git rev-parse origin/develop^{commit} # timeout=10 10:40:30 > git config core.sparsecheckout # timeout=10 10:40:30 > git checkout -f 7588941db5123456975ff1234567ef8733f20b0b # timeout=25 10:46:37 Commit message: "Merge branch '__branch_name_removed__' into 'develop'" 10:46:36 > git rev-list --no-walk 7588941db5123456975ff1234567ef8733f20b0b # timeout=10
We don't use the Jenkins issue tracker for question and answer sessions. Please use the Jenkins user mailing list or the Gitter chat channels for questions and answers.
Using Jira for questions and answers dramatically reduces the likelihood of receiving an answer, since there are many more people reading and responding to the mailing list and to Gitter chat than are monitoring the Jira issues for specific plugins. The people who monitor Jira issues are most often the same few people maintaining the specific plugin. When they spend time answering questions, that is time they do not spend improving the plugin .