Add jenkins pipeline.

[boaks]

Migration to new eclipse build infrastructure new eclipse build infrastructure.
Resets JAVA_TOOL_OPTIONS and _JAVA_OPTIONS in order to use java 1.7 for
build.

Signed-off-by: Achim Kraus achim.kraus@bosch-si.com

[boaks]

Currently tested with jobs 1.0.x-ci, 1.0.x-cd, 1.1.x-ci, 1.1.x-cd, 2.0.x-ci, and 2.0.x-cd using branches 1.0.x_pipes, master_pipes, 2.0.x_pipes.

If it's OK to go with declarative pipelines, I will create PRs for 1.0.x, master, and californium.tools as well. I will also prepare a release-job pipeline.

Using java 1.8 and compile for 1.7 would require a 1.7 classpath to check the api. FMPOV it's easier to reset the global env than to try to use java 1.8.

[sbernard31]

Naive question but what is benefits of using pipelines here ? just having build configuration in code repository ?

Using java 1.8 and compile for 1.7 would require a 1.7 classpath to check the api. FMPOV it's easier to reset the global env than to try to use java 1.8.

I didn't get the point here. Do we want to compile with java 7 or java 8 or both ?

[boaks]

We compile with java 7 for optimal java 7 compatibility.

[boaks]

Naive question but what is benefits of using pipelines here ? just having build configuration in code repository ?

Yes, to ensure, that "Resets JAVA_TOOL_OPTIONS and _JAVA_OPTIONS in order to use java 1.7" is applied. It's not required to use that pipeline on other jenkins instances nor to build californium locally.

[sbernard31]

I'm still confused.

I understand we want to compile with java 7.
And you suggest to use pipeline configuration file to set the java version to use.
But we can configure this in jenkins job configuration (JDK parameters).
Did I missed something ?

[boaks]

But we can configure this in jenkins job configuration (JDK parameters).

Only on an other jenkins instances, but not longer on the new eclipse build jenkins.

(I will add you to two bugs reported on https://bugs.eclipse.org)

Did I missed something ?

I guess the other.

[sbernard31]

I read bugzilla issues.
Can I play with https://ci-staging.eclipse.org/californium/job/2.0.x/ to better understand the issue?

[boaks]

Yes, it's easy to create a new job and use the "2.0.x" job to copy.

If you want to show, that java 8 is working, then please use the "master" job to copy :-).
And check the first OSCORE PR to see, why java 7 better complies to java 7 than java 8 (with option java 1.7). #516 (comment)

[boaks]

Just to mention:
you may also play with the declarative pipeline. it contains some instructions.

[sbernard31]

So my understanding,
On news Jenkins infrastructure, JAVA variables environment are configured like this :

JAVA_TOOL_OPTIONS=-XX:+IgnoreUnrecognizedVMOptions -XX:+UseContainerSupport -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
_JAVA_OPTIONS: -XX:MaxRAMPercentage=64.0

It seems that at least those options UseContainerSupport and MaxRAMPercentage are not really appreciated by java 7... (which returns Unrecognized VM option)

I expected that IgnoreUnrecognizedVMOptions would avoid this, but it seems this is not the case... (Maybe I don't understand the purpose of this .. or there is a jvm bug ?)

Anyway I see you found a workaround using shell command :

export _JAVA_OPTIONS=""
export JAVA_TOOL_OPTIONS=""
/opt/tools/apache-maven/latest/bin/mvn -f pom.xml -Dorg.eclipse.californium.elements.assume.TimeAssume.enable=true -DcreateJavadoc=true clean install

Any reason why you didn't go with this solution and prefer to use pipeline ?

Another solution could be to ask to eclipse to activate EnvInject to be able to override environment at job level.

I will ask to eclipse if they can fix/workaround this on their side because if there is other projects which use java 7 (at least Leshan), they will face the same issue.

Anyway I'm not against using pipeline, I don't know it so much and I just try to better understand the situation. :-)

[boaks]

I expected that IgnoreUnrecognizedVMOptions would avoid this, but it seems this is not the case... (Maybe I don't understand the purpose of this .. or there is a jvm bug ?)

That's obvious, that this should prevent the failure.
But it's not clear, which java (version? manufacturer?) supports it and a short web search haven't been successful. If it is a bug in java 7, I guess it will not be fixed.

[boaks]

Anyway I see you found a workaround using shell command :
Any reason why you didn't go with this solution and prefer to use pipeline ?

Three weeks ago, I would have agreed. But declarative pipelines are no big things.
(Compared to scripted-pipelines, which may be considered as big things).

But today, yes, there are reasons. Using maven in a declarative pipeline isn't complexer than in a shell script.

steps {
	sh "mvn $MVN_ARGS clean verify"
}

in fact, the pipeline uses the "sh" to invoke maven. The pipelines could be much easier used to create jenkins jobs. Declarative pipeline are more similar to a "import" for traditional, serialized jenkins jobs. OK, they not exactly the same, and you can't create them just by export. But using them feels more like importing a job and not "scripting something complex". May be that's the difference to scripted-pipelines. One thing, which seems to be important to obey:

• don't try to overwrite the git-stuff, when it is provided in the pipeline, in the job, if you want to use scm polling as trigger. That simply ends up in leave the git-stuff to the job and leave it out in the pipeline, but that's it.

One alternative approach would be to use java 8 and switch it to java 7 compatibility.
For californium one of my "home-jenkins" would then verify, that it really works with java 7.
But my feeling is, using pipelines for californium is the better approach.

[sbernard31]

To complete my bugzilla comment.

If you are only interested by overriding variable environment I feel adding build parameter is more straightforward. Go for pipeline if you just think that pipeline are better than job anyway.

Just a remark, you say that "it's hard to convince me", but read the discussion again trying to put yourself in my place and you will see it's hard to me to understand the situation with available information.

[sbernard31]

Clearly a detail but maybe we can add link the bugzilla issue.

[boaks]

Dear @sbernard31,
it seems that in the last weeks any of our discussions takes ages and ends up in a conflict.
On the otherside your dicusions with others are "harmonic and fast concluding".
So, to go faster ahead:
Please take over the work for the jenkins jobs, I don't want to spend my time anymore in it
Use, what ever you prefer.

[sbernard31]

I was not in a conflict spirit.
I was trying just to understand motivation of those changes.
I should not have reacted about "it's hard to convince me", that I probably over interpreted.

I was sincere when I said : "Anyway I'm not against using pipeline, I don't know it so much and I just try to better understand the situation. :-)" and "Go for pipeline if you just think that pipeline are better than Jenkins job anyway."