Hi Chris,
> : Unfortunately this is not so easy. It is always the same Jenkins Job,
> : the randomization is part of the dynamic JAVA_HOME. So the mail is
>
> Ah ... ok. What about adding a second (no mail configured) job for
> "untrusted" JDK9 (and if we start getting them: new IBM J9) builds?
>
> ie: your existing "main" job continues to randomize among the current JVMs
> and sends mail, but if/when new JVMs are available, you initially add them
> only to the randomization for the "untrusted" job -- watch it for ~week to
> see if it has any obvious problems, and then promote it to the "main" job
> (replacing the early minor version with the same major version) once you
> know it's not totally broken.
Not so happy, many jobs are hard to maintain. I will go soon to only have one
job anymore with a so-called "matrix config". You can add new axis to the
matrix, e.g. when a new release branch is added.
Anyways, I just figured out: We already have a groovy script in the extended
e-mail publisher (Steve Rowe wrote it). This script can cancel e-mail sending:
-----
Pre-send Script
This script will be run prior to sending the email to allow modifying the email
before sending. The MimeMessage variable is "msg," the build is also available
as "build" and a logger is available as "logger."
You may also cancel sending the email by setting the boolean variable "cancel"
to true.
----
This should just do something like (I hope the global bindings are there, so it
can get the environment variables):
cancel = JAVA_DESC.contains('-ea-');
Should work. It is too late today, will try this out tomorrow.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
