Temurin-build: Script tidy-up

[tellison]

A few good comments came up in discussion of #58 beyond fixing the lint warnings.

• Variables should use a consistent dereference style. The preferred project style is being discussed in #54 .
• Scripts should consistently be using set -eu (and we can discuss the possible use of set -euo pipefail)
• Review any dubious use of multi-value variables. Depending on splitting may be ok, but safer to use bash arrays explicitly.
• Decide how verbose we want commands, so consider dropping verbosity of tar.

[karianna]

And add our style to the CONTRIBUTING.md for future devs...

[gibfahn]

Decide how verbose we want commands, so consider dropping verbosity of tar.

Something like this often works well:

if [ "$DEBUG" ]; then
  VERBOSE="-v"
else
  VERBOSE=""
fi

Then you can just do tar "$VERBOSE" -xf in the scripts, and then at run time you can do DEBUG=1 ./scriptname.sh to enable DEBUG mode.

The other thing you can do is do:

#!/bin/bash -e${DEBUG:+x}

Which sets -x in the scripts if $DEBUG is defined.

Just a suggestion!

[karianna]

@gibfahn A good suggestion :-) - -x can be overly verbose so it makes sense to prvide our own definition of what $DEBUG provides

[gibfahn]

@karianna yep, the nice thing about having an agreed variable like $DEBUG defined everywhere is that you can tailor it to each script as you think best.

FWIW I tend to have -x always on in Jenkins, as I don't really care how big the logs are there, I just want to be able to see all the info, having to add echo statements and rerun an entire job is a pain.

[neomatrix369]

@karianna @tellison @gdams Should we close this issue, or do you have anything else in mind that need doing before we close it

[karianna]

@neomatrix369 I think updating our CONTRIBUTING.md with the style guide and applying the $DEBUG approach that @gibfahn suggested are still outstanding?

[neomatrix369]

@karianna ok on my to-do list, will have to gather all last conversations and filter it into the doc. Where is this CONTRIBUTING.md currently or we need to create a new one?
In the Wiki - https://github.com/AdoptOpenJDK/openjdk-build/wiki or as a project file so it is source controlled?

[karianna]

CONTRIBUTING.md will need to be a new file, it's a 'special' file in GitHub in that once you add one then contributors are reminded each PR to look over the guidelines before submitting. See openjdk-website for an example. It's added to the root of the repo

[neomatrix369]

We now have a Contributing.md, Although we do need something like a tech doc of guidelines to fulfil this issue. Any thoughts?

[karianna]

I think naming conventions for functions, using shell check etc are all valuable things to add to such a doc (and SRP principle)

[gdams]

Closing as the scripts were heavily refactored.