Please provide the java -version output of a nightly build on the nightly build download page

[pdbain-ibm]

Please provide the java -version output of each build on the download so users can track it
back to a git branch and commit. The "Checksum", i.e.
b909a21222813fbba0c2484ce33e1c63a503f556ba78a1466a018e41d9514217 OpenJDK10-OPENJ9_x64_Win_20180611.zip
doesn't appear to correspond to a commit in the OpenJ9 repo on github, nor in the AdoptOpenJDK repo.

[karianna]

Also see #264

[breun]

Note that java -version prints to standard error. :)

OpenJDK 11 and later also support java --version which prints to standard out, but OpenJDK 8 doesn't support this option. Of course redirecting standard error to standard out works too: java -version 2>&1

[gdams]

@johnoliver can this functionality be added to the v3 API?

[M-Davies]

@karianna Can this be transferred to the API Repo?

[karianna]

I'm not sure the original ask makes sense? Is the user try to tie back to an actual source code commit? I think we could provide that in the meta data

[M-Davies]

The OP of this has retired so it's possible he was before he left. We could just close this for now and reopen/link to it if someone else has this request?

Either way, I feel like this is something for the website or API team to deal with, not build.

[gdams]

Either way, I feel like this is something for the website or API team to deal with, not build.

@M-Davies I disagree, the only way to provide the java -version output to the API would be to add it to the JSON metadata.

[M-Davies]

The only way to provide the java -version output to the API would be to add it to the JSON metadata.

We produce a version.txt after each build. If we added that to the JSON metadata, would that suffice?

[gdams]

yes it should just be a case of adding that to the JSON metadata and then we can parse it in the API. There have also been separate requests to add the openjdk-build git sha and openjdk-jdku git sha to the metadata.

[M-Davies]

@gdams @karianna I'd like to get your opinion on two ideas for this

1. Add the version.txt to the VersionInfo class where it will eventually get put into the metadata towards the end of the build. It will then appear as part of the rest of the VersionInfo inside the metadata:

{
    "WARNING": "THIS METADATA FILE IS STILL IN ALPHA DO NOT USE ME",
    "os": "mac",
    "arch": "x64",
    "variant": "hotspot",
    "version": {
        "minor": 0,
        "security": 8,
        "pre": null,
        "adopt_build_number": 0,
        "major": 11,
        "version": "11.0.8+5-202006182334",
        "semver": "11.0.8+5.0.202006182334",
        "build": 5,
        "opt": "202006182334",
        "full_version_output": "
            openjdk version "11.0.8" 2020-07-14
            OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+5-202006182334)
            OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+5-202006182334, mixed mode)
        "
    },
    "scmRef": "",
    "version_data": "jdk11u",
    "binary_type": "jdk",
    "sha256": "6287770bf920a40fdc5d51d358c77228d070e356d8e27e6a44ae4322c5e742ee"
}

2. Add the version.txt to the Metadata class after the sha256 sum process is complete. This way, the full_version_output will be a direct attribute of the metadata instead of an attribute of the version attribute

{
    "WARNING": "THIS METADATA FILE IS STILL IN ALPHA DO NOT USE ME",
    "os": "mac",
    "arch": "x64",
    "variant": "hotspot",
    "version": {
        "minor": 0,
        "security": 8,
        "pre": null,
        "adopt_build_number": 0,
        "major": 11,
        "version": "11.0.8+5-202006182334",
        "semver": "11.0.8+5.0.202006182334",
        "build": 5,
        "opt": "202006182334"
    },
    "scmRef": "",
    "version_data": "jdk11u",
    "binary_type": "jdk",
    "sha256": "6287770bf920a40fdc5d51d358c77228d070e356d8e27e6a44ae4322c5e742ee",
    "full_version_output": "
        openjdk version "11.0.8" 2020-07-14
        OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+5-202006182334)
        OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+5-202006182334, mixed mode)
    "
}

[karianna]

I'm personally leaning toward option 2.

[M-Davies]

I'm personally leaning toward option 2.

I'm not convinced I can do that one anymore. We setup the version info class while the pipeline is still on the slave machine but we don't use the metadata one until we hit the master node, where the full_version_output and configure_arguments can no longer be accessed.

[karianna]

OK, so version 1 it is then :-)

[M-Davies]

Raised https://github.com/AdoptOpenJDK/openjdk-website/issues/739 to follow this up on the website side