| Re: [jakartaee-tck-dev] Weekly building of Jakarta Platform Stand-alone TCKs... |
_______________________________________________Hi Scott,
Yes both jakartaeetck-nightly-build-master & standalonetck-nightly-build-run-master are upstream freestyle jobs that calls the jakartaee-tck pipeline job(Jenkinsfile in the root directory of jakartaee-tck repo) . They are differentiated by using parameter 'BUILD_TYPE'. To create a new pipeline job for standalonetck-nightly-build-run-master job we could make use of the script corresponding to BUILD_TYPE='STANDALONE-TCK' from this Jenkinsfile.
I will try to explore more on how they can be converted to pipeline jobs in the CI. Meanwhile if someone has a better idea of how this can be done, please feel free to take this up.
I also have a feeling that the current OOM error is due to the large number of failures presently and could get resolved once we have better results.
Regards,
Alwin
On 02/06/20 8:20 PM, Scott Marlow wrote:
On Tue, Jun 2, 2020 at 9:52 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
On Mon, Jun 1, 2020 at 4:00 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
On Mon, Jun 1, 2020 at 2:45 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
Just to see if this has any impact on the OOM, [5] is only building the standalone TCKS that are not part of the Platform TCK, which should reduce the amount of Jenkins job results to collect at the end.
[5] seemed to be complete without hitting an OOM, so the next question is whether we need to raise the Java heap size or reduce the amount of Jenkins job results to avoid the OOM.
The quick response [6] is that the standalonetck-nightly-build-run-master needs to switch to be a pipeline job so that we can specify the container memory size + Java heap size for JNLP (similar to what we did for jakartaeetck-nightly-build-master via [7]). I also found [8] which discusses the problem with the default JNLP heap size being too small, as well.
Note that the jakartaeetck-nightly-build-master is also a freestyle Jenkins job, so that might also need to switch to be a pipeline job as well, if we hit similar OOM issues there.
Scott
I'll update issues#293 to mention this.
Does anyone want to volunteer to create a new pipeline job to replace the standalonetck-nightly-build-run-master freestyle job?
Scott
[6] https://www.eclipse.org/lists/cbi-dev/msg02239.html
Scott
Scott[5] https://ci.eclipse.org/jakartaee-tck/job/standalonetck-nightly-build-run-master/48
On Mon, Jun 1, 2020 at 12:41 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
Adding to the mystery, If I open [1] now, I no longer see the JNLP_PROTOCOL_OPTS environment variable setting that specifies -Xmx256m (I did save a copy of the web page with the -Xmx256m setting).
Since we do use the same https://ci.eclipse.org/jakartaee-tck/job/jakartaee-tck/job/master, I'm not really sure if the OOM during collection of job results is on the Jenkins slave VM or if it could possibly be on the Jenkins server. The answer should be in the exception call stack [3]. If the OOM is in Jenkins server, we may need to create a Eclipse CI ticket to tune the [4] Jenkins config.
Scott
On Sat, May 30, 2020 at 2:21 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
Hi Alwin, all,
I was just looking at the "java.lang.OutOfMemoryError: Java heap space" failure in standalonetck-nightly-build-run-master [1] , it looks like we have a max of 256mb used for the JNLP process according to injectedEnvVars [2], could someone please remind me where we are setting the environment variables for [2]? I'm thinking that we should go higher than -Xmx256m (512m or even 1-2g) in NLP_PROTOCOL_OPTS.
Thanks,Scott
[2] https://ci.eclipse.org/jakartaee-tck/job/standalonetck-nightly-build-run-master/45/injectedEnvVars/
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev