Temurin-build: La versión del archivo tiene una cadena de origen vacía: SOURCE = ""

También estoy interesado en esta información para definir de manera única una compilación (con los SHA de los repositorios que se extraen para crear el binario) para relacionar los resultados de la prueba con un binario en particular.

Hola, acabo de descargar y ejecutar 11.0.4 + 11 y el archivo de lanzamiento ahora tiene un git sha :-)

El árbol de origen de ese sha es https://github.com/AdoptOpenJDK/openjdk-jdk11u/tree/381c817fa41d549420b1f3a173d9147aa7a679cd

¿Hay alguna forma de ver el vínculo entre eso y la fuente en openjdk.java.net?

La etiqueta allí es 6a4d57474e1c971cccf4165b3d9d023928510010 y eso ocurre en openjdk-jdk11u / .hgtags

IMPLEMENTOR="AdoptOpenJDK" IMPLEMENTOR_VERSION="AdoptOpenJDK" JAVA_VERSION="11.0.4" JAVA_VERSION_DATE="2019-07-16" MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs" OS_ARCH="x86_64" OS_NAME="Windows" SOURCE=".:git:381c817fa41d"

Puede comparar con la etiqueta 11.0.4 + 11 en mercurial (que tendrá un hash de confirmación); todavía no tenemos un mapeo directo (ya que nuestra fuente de git se desvía técnicamente)

También estoy interesado en esta información para definir de manera única una compilación (con los SHA de los repositorios que se extraen para crear el binario) para relacionar los resultados de la prueba con un binario en particular.

@smlambert Con respecto a esto, https://github.com/AdoptOpenJDK/openjdk-build/pull/1949 ha entrado recientemente que agrega un hash git o una etiqueta git al campo scmref en nuestros metadatos . ¿Es eso lo que estás buscando?

En cuanto al problema original, hace mucho que pasamos de 11.0.2 (ahora estamos en 11.0.7), ¿se puede cerrar ya que los nuevos binarios tienen un hash de origen?

Genial, si lo entiendo correctamente, el contenido de SOURCE debería ser el SHA de los espejos git de AdoptOpenJDK (https://github.com/AdoptOpenJDK/openjdk-jdk11u, etc.) para hotspot, ¿está ahora presente en todas las versiones? 8 y 11+? para todas las implicaciones (aunque técnicamente solo puedo ver la salida de la versión de java para SHA para openj9, poder usar el mismo enfoque para consultar ambos es bueno).

Mirando dos nightlies recientes para JDK8 y 11 , puedo confirmar que JDK8 no contiene un valor fuente (sin embargo, JDK11 sí). 8 también contiene notablemente menos datos:

JAVA_VERSION="1.8.0_262"
OS_NAME="Darwin"
OS_VERSION="11.2"
OS_ARCH="x86_64"
SOURCE=""

IMPLEMENTOR="AdoptOpenJDK"
IMPLEMENTOR_VERSION="AdoptOpenJDK"
JAVA_VERSION="11.0.8"
JAVA_VERSION_DATE="2020-07-14"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Darwin"
SOURCE=".:git:824f8474f533"

ok, supongo que para jdk8 la historia puede ser un poco más complicada ... será bueno tenerla también para esa versión LTS, pero está bien hacerlo bajo otro problema, si desea cerrar este, que originalmente lo solicitó para jdk11

Cerrando esto y siguiendo JDK8 en https://github.com/AdoptOpenJDK/openjdk-build/issues/1966