BTW, this whole exercise is essentially only so that I could tag builds of the master branch with 0.0.$BUILD_NUMBER so that I could record these as "GitHub releases". Naturally, if there is a simpler approach to create these releases/tags instead of clone-tag-push, it'd simplify the whole process...
On Sunday, June 18, 2017 at 6:49:36 AM UTC+3, Idan Adar wrote: > > > - 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/6865d131-e3ed-4c4e-ac16-650b6f4213da%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
