FHIR Chat · Github CI Build · ibm

Stream: ibm

Topic: Github CI Build

Lee Surprenant (Oct 30 2019 at 15:47):

We just merged https://github.com/IBM/FHIR/pull/337 which adds a lot more jobs to our CI build. now it builds with:

1. java 8 and java 11 from the default "Zulu" build of openjdk
2. java 8 and java 11 from a recent nightly build of AdoptOpenJDK

Lee Surprenant (Oct 30 2019 at 15:48):

strangly we were hitting different issues on the two different builds of OpenJDK

Lee Surprenant (Oct 30 2019 at 15:48):

specifically, the Zulu JDK still has an issue when doing mutual auth

Lee Surprenant (Oct 30 2019 at 15:49):

@Paul Bastide worked around that issue by changing our fhir-server-test client to use basic auth by default (previously it was using client cert)

Lee Surprenant (Oct 30 2019 at 15:51):

before I close https://github.com/IBM/FHIR/issues/334 I wanted to hear from the team about whether we want to keep all these jobs, or just throw out the zulu ones

Lee Surprenant (Oct 30 2019 at 15:52):

also i wanted to guage interest in using https://github.com/marketplace/actions/setup-java-environment-based-on-adoptopenjdk ...this would let us define a single job and use a "test matrix" to have it run with both openjdk 8 and 11

Lee Surprenant (Oct 30 2019 at 15:53):

it also has the advantage of keeping us more up-to-date with openjdk nightlies

Lee Surprenant (Oct 30 2019 at 15:53):

without it, we have a wget of some recent snapshot build, and we'd need to remember to refresh that from time-to-time

Lee Surprenant (Oct 30 2019 at 15:54):

assuming it works, i think the only downside of using this action is the dependency on someones personal github action project

Paul Bastide (Oct 30 2019 at 15:55):

before I close https://github.com/IBM/FHIR/issues/334 I wanted to hear from the team about whether we want to keep all these jobs, or just throw out the zulu ones

I think we should do a final regression on release. the test-matrix is a similar approach that's on travis to 'switch_java'
I don't think we should run it every time

Lee Surprenant (Oct 30 2019 at 15:56):

FWIW my preference is to:

1. throw out the zulu jobs; and
2. use this guy's github action for the adoptopenjdk jobs

Paul Bastide (Oct 30 2019 at 15:56):

works for me.

John Timm (Oct 30 2019 at 15:56):

Same

Lee Surprenant (Oct 30 2019 at 15:58):

I think there is some benefit to running java 8 and java 11 each time (and currently no cost to do this)

Lee Surprenant (Oct 30 2019 at 15:58):

it helps catch any potential issues earlier in the process

Lee Surprenant (Oct 30 2019 at 15:58):

and prevents us from merging stuff that might break one or the other

Lee Surprenant (Oct 30 2019 at 16:41):

@Paul Bastide https://github.com/IBM/FHIR/pull/340 when you get a chance

Paul Bastide (Oct 30 2019 at 17:04):

please add --no-transfer-progress

Paul Bastide (Oct 30 2019 at 17:05):

it'll cut down on the mvn logs

Paul Bastide (Oct 30 2019 at 17:05):

or -ntp

Paul Bastide (Oct 30 2019 at 17:05):

trying to raise a proposed edit

Paul Bastide (Oct 30 2019 at 17:11):

only suggestions... not requires, as such marked LGTM

Lee Surprenant (Oct 30 2019 at 18:11):

thx paul, i took the suggestion

Lee Surprenant (Oct 30 2019 at 18:12):

will merge after build succeeds

Lee Surprenant (Oct 30 2019 at 18:12):

One related topic/question: I went back to java 8 locally and my build is now failing locally

Lee Surprenant (Oct 30 2019 at 18:12):

after thinking it through, i think its because fhir-examples had been build with java 11

Lee Surprenant (Oct 30 2019 at 18:13):

and we use the 1 class from that for our tests

Lee Surprenant (Oct 30 2019 at 18:13):

net: i'm pretty sure a class compiled for target: 11 CANNOT be run in a lower JVM

Lee Surprenant (Oct 30 2019 at 18:14):

it makes me think we should change it so that the target is always 1.8

Lee Surprenant (Oct 30 2019 at 18:14):

even when compiling with 11

Lee Surprenant (Oct 30 2019 at 18:14):

thoughts?

Lee Surprenant (Oct 30 2019 at 18:14):

is there any benefit to having the compile target be 11?

Lee Surprenant (Oct 30 2019 at 18:22):

https://stackoverflow.com/a/56064482/161022

Paul Bastide (Oct 30 2019 at 18:44):

One related topic/question: I went back to java 8 locally and my build is now failing locally

no way... this is a good to know

Paul Bastide (Oct 30 2019 at 18:44):

let me look at comptability

Paul Bastide (Oct 30 2019 at 18:45):

I think you were right with the sourceTarget testTarget 1.8

Paul Bastide (Oct 30 2019 at 18:45):

that was a great test

Lee Surprenant (Oct 30 2019 at 18:46):

based on this i've updated my PR to remove the java11 profile. folks can still pass -Djava.version=11 if they really wanna compile for java 11...but again i'm not sure what the benefit is

Lee Surprenant (Oct 30 2019 at 19:00):

grrr, now a test failure!

[ERROR] processExamples(com.ibm.fhir.server.test.R4ExampleServerTest)  Time elapsed: 107.564 s  <<< FAILURE!
javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class com.ibm.fhir.model.resource.ExplanationOfBenefit, ContentType: application/fhir+json.
    at com.ibm.fhir.server.test.R4ExampleServerTest.processExamples(R4ExampleServerTest.java:34)
Caused by: javax.ws.rs.WebApplicationException: HTTP 400 Bad Request
    at com.ibm.fhir.server.test.R4ExampleServerTest.processExamples(R4ExampleServerTest.java:34)

Lee Surprenant (Oct 30 2019 at 19:00):

found the stack traces above:

Caused by: java.io.InterruptedIOException: Input operation aborted
    at org.apache.cxf.transport.http.asyncclient.SharedInputBuffer.waitForData(SharedInputBuffer.java:183)
    at org.apache.cxf.transport.http.asyncclient.SharedInputBuffer.read(SharedInputBuffer.java:262)
    at org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit$AsyncWrappedOutputStream$6.read(AsyncHTTPConduit.java:690)
    at java.io.FilterInputStream.read(FilterInputStream.java:133)
    at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
    at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
    at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
    at java.io.InputStreamReader.read(InputStreamReader.java:184)
    at org.glassfish.json.JsonTokenizer.fillBuf(JsonTokenizer.java:495)
    at org.glassfish.json.JsonTokenizer.read(JsonTokenizer.java:456)
    ... 68 more

Lee Surprenant (Oct 30 2019 at 19:00):

cant seem how my change would break that

Lee Surprenant (Oct 30 2019 at 19:00):

clicking re-run check

John Timm (Oct 30 2019 at 19:14):

That exception stack trace looks awfully familiar...

Lee Surprenant (Oct 30 2019 at 19:15):

similar to, but different io exceptions from the ones we were seeing on that other issue i think

Lee Surprenant (Oct 30 2019 at 19:56):

all tests passed this time. i'm gonna merge this one.

Lee Surprenant (Oct 30 2019 at 19:57):

and work on a change to hopefully get better exception if we hit similar i/o issue again

Paul Bastide (Oct 30 2019 at 20:25):

strange

Last updated: Apr 12 2022 at 19:14 UTC