[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] Being green and reducing our Jenkins CI usage...
|
On 09/07/20 9:08 pm, Scott Marlow wrote:
On 7/7/20 2:05 PM, Scott Marlow wrote:
Hi,
I heard some general feedback that we are consuming more resources
than expected with our jakartaee-tck environment. I don't have
specifics at the moment but am thinking that we could update
the jakartaeetck-nightly-build-master [1] job to only run if a change
was merged to the TCK repo [2]. Any volunteers from the committers
to work on this change? Only the committers have permissions to
update the Jenkins job [1] to poll the SCM (git).
Just to understand, does "consuming more resources" means we are running
jobs more often or we are using more storage?
Ideas are welcome :)
The jakartaeetck-nightly-build-master [1] currently runs every night,
regardless of whether there are any changes made to the Platform TCK
repo. We could update jakartaeetck-nightly-build-master [1] to
reference the jakartaee-tck git repo [2], however that adds the
additional cost of cloning the git repo (such that building the
Platform TCK takes even more time versus some time savings on days
when there are no TCK code changes).
I'm leaning towards trying to add the git repo [2] to the
jakartaeetck-nightly-build-master [1] job, so that we reduce the
overall time consumed.
I think using git hooks could solve this, to trigger the job when there
is a commit. But above idea could be better to run it as per the schedule.
Scott
I also have been thinking about further changes to the JNLP memory
settings in [3]. More specifically, we could try reducing
the -Xmx2048m setting to a lower value that is still higher than the
-Xmx512m that we previously used, it is guesswork mostly. If we
switched to -Xmx1024m, we likely will use more cpu (e.g. running more
frequent GCs) but that might free up other VM/OS level memory for
kernel use. We would need to measure the before/after result of such
a change. If the TCK runs are faster with this change, we would it
keep it. If the TCK runs are slower or have more test failures, we
would revert it.
I suggest we check with eclipse infra to get the total number of
agents/resources available for jakartaee-tck CI. Agree that it is
difficult to do adjustments here as it needs more trial-error way to
figure out the right memory/cpu configuration.
Scott
[1]
https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-build-master/
[2] https://github.com/eclipse-ee4j/jakartaee-tck
[3]
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/Jenkinsfile#L130
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev