Update hardcoded JDK next values

[ShishirH]

#1514

Closes #1514

Signed-off-by: Shishir Halaharvi [email protected]

[ShishirH]

@adam-thorpe Please let me know if there is anything left to be done.

[adam-thorpe]

Think it was just those two values, thanks @ShishirH

[jerboaa]

Ideally, we'd handle the case explicitly when System.getenv(...) returns empty. I.e. the environment variable is not set. I'd suggest a similar course of action as in the else branch.

Please also remove the comment as it's no longer true.

[ShishirH]

@jerboaa Made suggested changes

[jerboaa]

LGTM. Nit: Perhaps we should be explicit and write Environment variable JAVA_FEATURE_VERSION not set. You can make that change when you push.

[ShishirH]

@jerboaa Updated the message.

[jerboaa]

Looks good.

[johnoliver]

I am not sure where we would set JAVA_FEATURE_VERSION so that these scripts would pick it up

[johnoliver]

I realise my last comment was a bit cryptic, for further info, the scripts you are changing execute on the Jenkins master server, I am not sure they even are able to access the environment variables due to the jenkins sandbox, but also I am not sure we have a good way of setting that environment variable in the context of the jenkins scripts.

[karianna]

As per @johnoliver comment where / How does JAVA_FEATURE_VERSION get set?

[jerboaa]

@karianna @johnoliver:

early on in build-farm/make-adopt-build-farm.sh:

https://github.com/AdoptOpenJDK/openjdk-build/blob/master/build-farm/make-adopt-build-farm.sh#L26
https://github.com/AdoptOpenJDK/openjdk-build/blob/master/build-farm/make-adopt-build-farm.sh#L32

Would jenkins master not execute this?

[adam-thorpe]

Looking at @sxa555 's lovely diagram in #957, make-adopt-build-farm.sh is called after build_base_file.groovy and openjdk_build_pipeline.groovy so the value is set later on (i.e. once the job has been initialised by jenkins)

[johnoliver]

Yes that is correct, the groovy files are run by jenkins to setup and configure the jobs, make-adopt-build-farm.sh comes after to do the actual build on the node. So JAVA_FEATURE_VERSION should not be set from inside the groovy code

[ShishirH]

@johnoliver @adam-thorpe If I understand correctly, due to the scripts running before the groovy code, the hardcoding shouldn't be removed, and both this PR and issue should be closed without merging, right?

[johnoliver]

@ShishirH its the other way around, since the groovy runs before the scripts so the variable is not set for the groovy to pick up. Removing the hardcoding is good so I would like to find a way around it. One thing to note is that you can set global environment variables inside Jenkins, so this PR would work if you did that. Its possible we could use Jenkins global environment variables as a central place to encode what the most recent version is.

It is an open question as to where we want to centralise this most recent version number information rather than have it scattered around lots of scripts. The api may be the correct place for it, or possibly putting it in Jenkins via a statically hosted file or environment variable. @karianna or @sxa555 may have an opinion on which would be better.

[karianna]

The API is intriguing as it decouples us from Jenkins (we're too tightly coupled as it is). Are you thinking of something like https://api.adoptopenjdk.net/latest_jdk_version which would return say 15?

[johnoliver]

@karianna yeah, something we can bump in a single place to pretty much say what version head is, then other scripts like docker stuff can read from there too.

[karianna]

@johnoliver Works for me, let's do it.

[M-Davies]

Created AdoptOpenJDK/openjdk-api-v3#212 to follow up on this