Update base image

[jburel]

Attempting to get the BioFormats-image job green in new jenkins-CI
Currently failure due to

Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on project ome-common: There are test failures.

The change also matches the arguments in BF-build job

[sbesson]

Interesting. These tests are definitely picked up and executed daily in existing devspaces e.g. https://merge-ci.openmicroscopy.org/jenkins/job/BIOFORMATS-image/1065. Since this is a building from scratch, one potential source of divergence worth investigating is the base Docker image.

[jburel]

Looking at the Image
There is a difference between the version of merge-ci and updated jenkins-ci
Recent update see https://github.com/docker-library/openjdk

[sbesson]

Looking quickly at it locally, it looks like we are hitting https://stackoverflow.com/q/23260057. Amongst possible suggested solutions, one of them might be to revert #58 (i.e. it looks like we had already had this issue in the past)

[jburel]

the commit 441e5ea did not break the build on the updated infra

[jburel]

When running locally I have errors when building the javadoc

100 errors
#14 580.3 100 warnings
#14 580.3 [ERROR] MavenReportException: Error while generating Javadoc: 
#14 580.3 Exit code: 1 - /bio-formats-build/ome-poi/src/main/java/loci/poi/hpsf/ClassID.java:218: error: unexpected end tag: </p>
#14 580.3      * <code>false</code>.</p>
#14 580.3                           ^
#14 580.3 /bio-formats-build/ome-poi/src/main/java/loci/poi/hpsf/ClassID.java:51: error: malformed HTML
#14 580.3  * @author Rainer Klute <a
#14 580.3                         ^
#14 580.3 /bio-formats-build/ome-poi/src/main/java/loci/poi/hpsf/ClassID.java:52: error: bad use of '>'
#14 580.3  * href="mailto:klute@rainer-klute.de">&lt;klute@rainer-klute.de&gt;</a>
#14 580.3                                       ^
#14 580.3 /bio-formats-build/ome-poi/src/main/java/loci/poi/hpsf/ClassID.java:52: error: unexpected end tag: </a>
#14 580.3  * href="mailto:klute@rainer-klute.de">&lt;klute@rainer-klute.de&gt;</a>
#14 580.3                                                                     ^
#14 580.3 /bio-formats-build/ome-poi/src/main/java/loci/poi/hpsf/Constants.java:46: error: malformed HTML
#14 580.3  * @author Rainer Klute <a
#14 580.3                         ^
#14 580.3 /bio-formats-build/ome-poi/src/main/java/loci/poi/hpsf/Constants.java:47: error: bad use of '>'
#14 580.3  * href="mailto:klute@rainer-klute.de">&lt;klute@rainer-klute.de&gt;</a>
#14 580.3        

[jburel]

@dgault have you seen this error before?

[sbesson]

@jburel should the title of this PR be updated as it is allowing the tests to be run on new JDK versions rather than skipping them

[dgault]

I've never seen any of those before, Im assuming there must be extra or stricter checking going on here. When I get some free time I will try to reproduce locally

[jburel]

It looks like the image is older in the new devspace

docker inspect openjdk:8 | grep Created
        "Created": "2019-03-05T04:04:10.522942166Z",

and merge-ci

docker inspect openjdk:8 | grep Created
        "Created": "2021-07-22T13:37:31.954806499Z",

That probably explains what the divergence we noticed

[sbesson]

So is the next step to pull a recent Docker image, exclude this and see if the problem is fixed?

[jburel]

I have

• modified the Dockerfile so a recent image is pulled
• removed flag re-introduced with 441e5ea

[jburel]

The title has been modified to reflect the change.
I could force push a commit if required.
The errors seen in the testing ci match the errors seen today on merge-ci i.e.

(    formats/tiff: line   33) broken    https://www.adobe.io/open/standards/TIFF.html - 404 Client Error: Not Found for url: https://developer.adobe.com/open/standards/TIFF.html

[sbesson]

I think I convinced myself that pinning the base image to a specific JDK version as proposed here will help making things more reproducible and simplify troubleshooting. It would be good to have additional sign-offs from the team to be sure we are not missing some important use cases.

[jburel]

@dgault what do you think about pinning the version?

[dgault]

Fixing to a specific version seems like a sensible approach to me, should keep things more consistent. Looks good from my side.