-
Bug
-
Resolution: Incomplete
-
Major
-
master runs on Windows Server 2012
Jenkins 2.8
we are migrating our jobs to the multibranch pipelines, about a dozen or more.
all of them work fine, but one repository wouldn't pass the branch indexing process. the process gets stuck and eventually fails with the following log message:
Setting origin to https://git..... Fetching origin... Finished: NOT_BUILT
after double and triple checking all our configurations and repositories, we couldn't find any difference between this repository and the others. I went through the Jenkins Log and found out that whenever this particular branch indexing fails the log prints out a java heap out of memory error.
it doesn't show the full message on every such error, so I can only assume the first one of those is the relevant full stack trace:
Jun 08, 2016 11:31:22 AM SEVERE hudson.model.Executor finish1 Executor threw an exception java.lang.OutOfMemoryError: Java heap space at org.eclipse.jgit.internal.storage.pack.BinaryDelta.apply(BinaryDelta.java:163) at org.eclipse.jgit.internal.storage.pack.BinaryDelta.apply(BinaryDelta.java:118) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:610) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:587) at org.eclipse.jgit.transport.PackParser.resolveDeltas(PackParser.java:550) at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:507) at org.eclipse.jgit.internal.storage.file.ObjectDirectoryPackParser.parse(ObjectDirectoryPackParser.java:194) at org.eclipse.jgit.transport.PackParser.parse(PackParser.java:448) at org.eclipse.jgit.transport.BasePackFetchConnection.receivePack(BasePackFetchConnection.java:762) at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:363) at org.eclipse.jgit.transport.TransportHttp$SmartHttpFetchConnection.doFetch(TransportHttp.java:783) at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:301) at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:291) at org.eclipse.jgit.transport.FetchProcess.fetchObjects(FetchProcess.java:247) at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:160) at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122) at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138) at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.fetch(JGitAPIImpl.java:678) at jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:174) at jenkins.scm.api.SCMSource.fetch(SCMSource.java:146) at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:294) at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:157) at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:122) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410)
again - we have no idea what makes the difference. the repository itself isn't bigger than the others, we don't have special characters in our branch names (only alphanomerics . - _ and such. no spaces and no escaped chars) and all the repositories are hosted in Assembla.
running this same job as a regular pipeline job works. it's only the branch indexing that causes this problem. so my guess is that the heap space should be sufficient, but something somehow throws the indexing process into an infinite recursion (or something of the kind).