Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] Building maven artifacts for Eclipse SUMO

Hi Robert,

At DriftFX have a similar problem. We are building native bits for all 3 major platforms at Github.

At Eclipse Jenkins we don't do any building but just grab the artifacts from GitHub and:
* sign them
* upload them to


Am 19.03.21 um 17:12 schrieb Robert.Hilbrich@xxxxxx:
Hi CBI-Dev members,

the Eclipse SUMO project is currently hosted on GitHub, based on C++ and built with GitHub actions & cmake. As part of our build process, we also create jars (java-bindings for an interface to SUMO – see: <>), which we would like to make publicly available for maven builds. Unfortunately, GitHub Packages require an access token to consume maven artifacts which is a show stopper for other projects relying on our packages. Therefore, we decided to use the Eclipse infrastructure and opened a bug to have <> created for us. So far so good …

Unfortunately, we cannot push the artifacts from the GitHub actions build to <>, because upload from external sources is currently not possible. Therefore, our only options seems to be to also build SUMO on Jenkins (in addition to the GitHub actions) and to publish the artifacts from the Jenkins build.

We tried to go through the wiki page and experimented with a basic Jenkinsfile on (see: <>). For this purpose, we started with a “Multibranch Pipeline” configuration ( <>). However, the repository cloning process already fails at 58% with an exception – as seen in the logs below.

Our questions are:

  * Is our approach ok? Is there a better way to achieve our goal?
  * How can we successfully clone the repo in the container
    infrastructure? Yes – the repo of SUMO has grown to a repo size of
    750MB over the years …
  * How can we use an ubuntu image with cmake and gcc to build SUMO
    (instead of maven:alpine)?
  * How can we configure the infrastructure to trigger the Jenkins build
based on tagged commits to the GitHub Repository master branch only?
Thank you for your help – best regards,

Robert Hilbrich

Excerpt from <>:

“Resolving deltas:  58% (241715/415811)

error: index-pack died of signal 9

fatal: index-pack failed

        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(

        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(

        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(

        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(

        at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(

        at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$

        at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$

         at hudson.remoting.UserRequest.perform(

         at hudson.remoting.UserRequest.perform(

         at hudson.remoting.Request$

        at hudson.remoting.InterceptingExecutorService$

        at java.base/

        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(

        at java.base/java.util.concurrent.ThreadPoolExecutor$

         at hudson.remoting.Engine$1.lambda$newThread$0(

        at hudson.remoting.Engine$1$$Lambda$33/ Source)

         at java.base/

        Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from

               at hudson.remoting.Channel.attachCallSiteStackTrace(

               at hudson.remoting.UserRequest$ExceptionResponse.retrieve(


               at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(

               at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

               at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(

               at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(

               at java.base/java.lang.reflect.Method.invoke(

               at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(

                at com.sun.proxy.$Proxy106.execute(Unknown Source)

               at hudson.plugins.git.GitSCM.retrieveChanges(

                at hudson.plugins.git.GitSCM.checkout(

               at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(

               at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$

               at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$

               at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(

               at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$$Lambda$701/ Source)

               at java.base/java.util.concurrent.Executors$

               at java.base/

               at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(

               at java.base/java.util.concurrent.ThreadPoolExecutor$

... 1 more


*German Aerospace Center*(DLR)

Institute of Transportation Systems | Rutherfordstraße2 | 12489 Berlin

*Dr. Robert Hilbrich | Team Leader Simulation of Mobility Systems*

Telefon 030 67055-582 | Telefax 030 67055-291 | Robert.Hilbrich@xxxxxx <mailto:Robert.Hilbrich@xxxxxx> <>| Institute of Transportation Systems <>

cbi-dev mailing list
To unsubscribe from this list, visit

Back to the top