[
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 repo.eclipse.org
Tom
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:
https://github.com/orgs/eclipse/packages?repo_name=sumo
<https://github.com/orgs/eclipse/packages?repo_name=sumo>), 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
https://repo.eclipse.org/content/repositories/sumo/
<https://repo.eclipse.org/content/repositories/sumo/> created for us. So
far so good …
Unfortunately, we cannot push the artifacts from the GitHub actions
build to http://repo.eclipse.org <http://repo.eclipse.org>, 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 ci.eclipse.org (see:
https://github.com/eclipse/sumo/blob/master/Jenkinsfile
<https://github.com/eclipse/sumo/blob/master/Jenkinsfile>). For this
purpose, we started with a “Multibranch Pipeline” configuration
(https://ci.eclipse.org/sumo/job/sumo-build/
<https://ci.eclipse.org/sumo/job/sumo-build/>). 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 https://ci.eclipse.org/sumo/job/sumo-build/job/master/
<https://ci.eclipse.org/sumo/job/sumo-build/job/master/>:
“Resolving deltas: 58% (241715/415811)
error: index-pack died of signal 9
fatal: index-pack failed
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2450)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2051)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:84)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:573)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:802)
at
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161)
at
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:375)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:73)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:118)
at
hudson.remoting.Engine$1$$Lambda$33/0x000000007c0116d0.run(Unknown Source)
at java.base/java.lang.Thread.run(Thread.java:836)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote
call to JNLP4-connect connection from 10.128.12.1/10.128.12.1:33512
at
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1800)
at
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:1001)
at
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy106.execute(Unknown Source)
at
hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1221)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1299)
at
org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:125)
at
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93)
at
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80)
at
org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at
org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$$Lambda$701/0x000000004c0285f0.run(Unknown
Source)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
... 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>
www.DLR.de <http://www.dlr.de/>| Institute of Transportation Systems
<http://www.dlr.de/ts>
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cbi-dev