Temurin-build: A liberação do arquivo tem uma string de origem vazia: SOURCE = ""

Também estou interessado nesta informação para definir exclusivamente uma compilação (com os SHAs de repos sendo puxados para criar o binário) a fim de relacionar os resultados do teste a um binário específico.

Olá, acabei de baixar e executar 11.0.4 + 11 e o arquivo de lançamento agora tem um git sha nele :-)

A árvore de origem desse sha é https://github.com/AdoptOpenJDK/openjdk-jdk11u/tree/381c817fa41d549420b1f3a173d9147aa7a679cd

Existe uma maneira de ver o link entre isso e a fonte em openjdk.java.net?

A tag é 6a4d57474e1c971cccf4165b3d9d023928510010 e ocorre em 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"

Você pode comparar com a tag 11.0.4 + 11 no mercurial (que terá um hash de commit) - não temos um mapeamento direto ainda (já que nosso código-fonte git tecnicamente diverge)

Também estou interessado nesta informação para definir exclusivamente uma compilação (com os SHAs de repos sendo puxados para criar o binário) a fim de relacionar os resultados do teste a um binário específico.

@smlambert Com relação a isso, https://github.com/AdoptOpenJDK/openjdk-build/pull/1949 foi recentemente que adiciona um hash git ou tag git ao campo scmref em nossos metadados . É isso que você está procurando?

Quanto ao problema original, já passamos do 11.0.2 (agora estamos no 11.0.7). Isso pode ser fechado porque os novos binários têm um hash de origem?

Ótimo, então, se bem entendi, o conteúdo de SOURCE deve ser o SHA dos espelhos git AdoptOpenJDK (https://github.com/AdoptOpenJDK/openjdk-jdk11u, etc) para hotspot, agora está presente para todas as versões? 8 e 11+? para todos os impls (embora eu possa, tecnicamente, apenas olhar a saída da versão java para SHAs para openj9, ser capaz de usar a mesma abordagem para consultar os dois é bom).

Olhando para dois nightlies recentes para JDK8 e 11 , posso confirmar que JDK8 não contém um valor de origem (JDK11, no entanto). 8 também contém visivelmente menos dados:

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, acho que para jdk8 a história pode ser um pouco mais complicada ... será bom tê-lo para essa versão LTS também, mas é bom fazer isso em outra edição, se você deseja fechar este, que originalmente solicitou para jdk11

Fechando isso e acompanhando o JDK8 em https://github.com/AdoptOpenJDK/openjdk-build/issues/1966