@rhoughton - sounds reasonable. JDK8 Unit tests are added back to PR checks
now.
@jbarrett - good point, no need to skip analyze-serializables test when
compiled with JDK8. Jinmei has a PR to un-skip:
https://github.com/apache/geode/pull/3607
@dschneider - do you still want to bring back all
I that the serialization test was only an issue when compiled with JDK11? We
don’t compile with JDK11, we compile with JDK8 and run under JDK11.
> On May 20, 2019, at 8:50 AM, Robert Houghton wrote:
>
> The PR pipeline should be a timely test, but also sane and helpful. Maybe
> making the JDK8
The PR pipeline should be a timely test, but also sane and helpful. Maybe
making the JDK8 Unit tests (but not the integration, etc) part of PR is a
good compromise in that sense.
On Sun, May 19, 2019 at 2:20 AM Owen Nichols wrote:
> Correct, analyze-serializables test is currently skipped under
I think it would be a mistake to have just the main pipeline catch
analyze-serializable failures. It is easy to accidentally cause these
failures so I think we want them caught early. They are also not flaky so
if broken then they will consistently fail. I think this would cause
someone extra work
Correct, analyze-serializables test is currently skipped under JDK11. Ideally
it would be re-written to test what is actually serialized, not the flawed
assumption that no change in compiled bytecode size means nothing changed...
This also brings up a good question worth discussing: is the goal
One problem with doing this, I think, is that we have some tests that are
disabled unless run on 8. They are the analyze serializables tests. I'm not
sure of the details but I think the "golden" checksums these tests compare
to were generated from the byte codes from the jdk 8 class files. The byte
I’ve created a PR for this, please give it a +1:
https://github.com/apache/geode/pull/3598
> On May 16, 2019, at 11:12 AM, Anilkumar Gingade wrote:
>
> Make sense to me...Looking at the probability of breaking specific to, jdk8
> and jdk11 through a commit.
>
>
> On Wed, May 15, 2019 at 6:09
Make sense to me...Looking at the probability of breaking specific to, jdk8
and jdk11 through a commit.
On Wed, May 15, 2019 at 6:09 PM Owen Nichols wrote:
> Currently every PR commit triggers both JDK8 and JDK11 versions of each
> test job. I propose that we can eliminate the JDK8 version of
Currently every PR commit triggers both JDK8 and JDK11 versions of each test
job. I propose that we can eliminate the JDK8 version of each check. In the
extremely rare case where a code change breaks on Java 8 but works fine on Java
11, it would still be caught by the main pipeline (just as Wi
