- An intentionally narrow refspec (like
+refs/heads/master:refs/remotes/origin/master) reduces the objects copied
in the clone to only those in that refspec (typically the desired branch),
while still providing the full history of the working branch (but not the
history of other branches in the repository)
Is this relevant in a multibranch job? I thought that in this job that
specifies "master develop" branches, a checkout of the develop branch
checks out just the develop branch and a checkout of the master branch
checks out just the master branch. Seems narrow enough?
If Stephen's changes will really simply allow me to git push as part of the
default "checkout scm" command, I could just do that without trying to
customize it... as I would be fine with the single checkout and then
operate it on (instead of the forced git cloning I need to do now in order
to git push).
BTW, trying that checkout customization in my previous post failed with an
exception...
java.lang.NullPointerException
at
org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState.get(MultiSCMRevisionState.java:56)
at
org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:106)
at
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83)
at
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73)
at
org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
at hudson.security.ACL.impersonate(ACL.java:260)
at
org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
On Sunday, June 18, 2017 at 1:42:58 AM UTC+3, Mark Waite wrote:
>
>
>
> On Saturday, June 17, 2017 at 11:48:19 AM UTC-6, Idan Adar wrote:
>>
>> Okay, so looks like what I should try in order to:
>> 1. make checkouts faster
>> 2. be able to git tag & push
>>
>> Is the following:
>>
>> 1. Try with:
>>
>> checkout(
>> extensions: [
>> [$class: 'CloneOption',
>> depth: 1,
>> shallow: true
>> ]
>> ]
>> )
>>
>>
>>
> I look forward to hearing that it helped with your use case.
>
> There are several ways to reduce the work done by git fetch or git clone,
> each with its own set of reasons it helps and reasons it hinders. For
> example:
>
> - An intentionally narrow refspec (like
> +refs/heads/master:refs/remotes/origin/master) reduces the objects copied
> in the clone to only those in that refspec (typically the desired branch),
> while still providing the full history of the working branch (but not the
> history of other branches in the repository)
> - A reference repository updated on the agent (by whatever means you
> wish) can avoid network copies of objects by allowing git fetch and git
> clone to point to the references instead of retrieving them. This can be
> a major savings with large repositories, since multiple jobs can point to
> a
> single copy of the reference repository and save disc space and network
> transfer
> - Large file support (LFS) can reduce network transfers by only
> transferring the current copy of large files which are being tracked,
> rather than transferring the entire history of large files. LFS requires
> a
> newer version of git, changes in the repository, and some extra setup for
> support from the git server
> - A sparse checkout can reduce the disc usage of the working directory
> by only performing a checkout of the specified subdirectories
> - Avoiding fetch of tags can reduce network transfer by not copying
> the objects associated with tags
> - A shallow clone can reduce network data transfer by only copying a
> subset of history into the working directory. Depth beyond a single digit
> value has not seemed to be any different than not having shallow clone in
> the cases I've seen. Shallow clone sometimes fails on older git versions
> (like the git included with CentOS 6 and earlier)
>
> Slides from Jenkins World 2016 that discuss several of those options are
> available at
> https://jenkins.io/files/2016/jenkins-world/large-git-repos.pdf .
>
> If you prefer video, there is a roughly 5 minute segment on git, Jenkins,
> and large repositories in https://www.youtube.com/watch?v=TsWkZLLU-s4 .
>
> Mark Waite
>
> 2. Wait for Stephen...
>>
>>
>>
>> BTW, I thought the shallow cloning is basically to specify depth, so why
>> shallow:true is needed in additition to depth:1 ?
>>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/007f0918-a64b-4a47-947d-be7944507eae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
