Automate building reports using Docker and SDKMAN #9
Conversation
pivovarit
changed the title
|
|
||
| RUN echo '<?xml version="1.0" encoding="UTF-8"?>' > /usr/share/maven/conf/toolchains.xml | ||
| RUN echo '<toolchains xmlns="http://maven.apache.org/TOOLCHAINS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/TOOLCHAINS/1.1.0 http://maven.apache.org/xsd/toolchains-1.1.0.xsd">' >> /usr/share/maven/conf/toolchains.xml | ||
| RUN echo "<toolchain><type>jdk</type><provides><version>10</version><vendor>openjdk</vendor></provides><configuration><jdkHome>$HOME/.sdkman/candidates/java/$JDK1</jdkHome></configuration></toolchain>" >> /usr/share/maven/conf/toolchains.xml |
There was a problem hiding this comment.
How is the interaction with this toolchains.xml file intended to be? Shouldn't the versions (10, 11) be configurable?
There was a problem hiding this comment.
Ideally, removed(#10) :) we could just feed two JAVA_HOMEs to Maven builds instead of configuring them via toolchains.xml
But here, I assumed that containers are throw-away so although the values there are hardcoded, the actual content gets substituted (and versions are resolved based on java -version and not on the toolchain entry name)
| RUN curl -s http://get.sdkman.io | bash | ||
|
|
||
| ARG JDK1 | ||
| RUN test -n "$JDK1" || (echo "JDK1 build-arg not provided - choose one from:" && bash -c "source $HOME/.sdkman/bin/sdkman-init.sh && sdk l java" && false) |
There was a problem hiding this comment.
How about getting the JDKs via a volume from the host? This would avoid the repeated download for building version-specific images. WDYT?
There was a problem hiding this comment.
So, my assumption was that if someone wants to just try it, that would be handy to have that fully automated.
If someone wants to pass volumes from the host, they can just simply run the code without using the Docker-based solution - but naturally, that could be added as well
The added value here is the fact that you don't need to configure much in order to get a report and is not supposed to replace the bare solution
There was a problem hiding this comment.
Notice how easy CI becomes thanks to that:
https://github.com/AdoptOpenJDK/jdk-api-diff/blob/0292872fcfb7705eb5d648cd16be7d7137337ff2/.github/workflows/build.yml
|
@gunnarmorling Should we proceed with this PR? |
|
After such a long time... it's probably not working anymore. But I'm willing to update it if needed. |
The process of setting up the environment for the sake of generating a report was in my case a bit tedious so I automated and encapsulated all of that in a single Dockerfile - making it possible to generate reports without downloading multiple JDKs and messing up with Maven's
toolchains.xml.Parameter names (especially JDKs) remained unchanged and might seem just wrong (just as the JDK version of the builder) - wanted to make the change minimally invasive so I adapted to the existing shape of the codebase.
At the end of the build, the
jdk-api-diff.htmlspawns in a directory from which the command was called.In order to build an example report between SDKMAN distributions tagged
11.0.5-openand12.0.2-open, run:./compare.sh 11.0.5-open 12.0.2-openwhich becomes effectively:
If you don't know what available distributions are, run the script without providing build-args:
./compare.shor just:
Depends on: #8 ✅