Added abilitiy to build RPM and DEB files locally

[jmjaffe37]

Title

[gdams]

Same comment as the other PR, please can you add the same support to the /linux/jre directory too

[jmjaffe37]

Note:
If we change this line from:
rpmbuild --nodeps -bs "$spec"; # build src.rpm
to
rpmbuild --define "local_build ${buildLocalFlag}" \
--nodeps -bs "$spec"; # build src.rpm

(And pretty much the same change here)

Then this will simplify the logic in the spec files for determining whether or not a vendor is building locally or not. Currently, my workaround can be seen in the Microsoft installers PR, but it is a little ugly.

This line (the definition for the local_build variable) would simplify to be written the same way as the definition of override_arch_ (currently on line 19 of the same file) if the --define change is ok with everyone. I believe that defining this variable (which I arbitrarily named), should not mess with anyone's builds since it is up to the specfile to add logic to use this variable or not, but wanted to ask what others think before making this change

[karianna]

Note: If we change this line from: rpmbuild --nodeps -bs "$spec"; # build src.rpm to rpmbuild --define "local_build ${buildLocalFlag}" \ --nodeps -bs "$spec"; # build src.rpm

(And pretty much the same change here)

Then this will simplify the logic in the spec files for determining whether or not a vendor is building locally or not. Currently, my workaround can be seen in the Microsoft installers PR, but it is a little ugly.

This line (the definition for the local_build variable) would simplify to be written the same way as the definition of override_arch_ (currently on line 19 of the same file) if the --define change is ok with everyone. I believe that defining this variable (which I arbitrarily named), should not mess with anyone's builds since it is up to the specfile to add logic to use this variable or not, but wanted to ask what others think before making this change

That seems sane to me, I'm not sure if we would need to change any calling scripts in the Adoptium pipelines though. Let's try the change and see if it passes the GH checks and then figure out if there is a caller script in Jenkins that also would need updating.

[jmjaffe37]

Note: If we change this line from: rpmbuild --nodeps -bs "$spec"; # build src.rpm to rpmbuild --define "local_build ${buildLocalFlag}" \ --nodeps -bs "$spec"; # build src.rpm
(And pretty much the same change here)
Then this will simplify the logic in the spec files for determining whether or not a vendor is building locally or not. Currently, my workaround can be seen in the Microsoft installers PR, but it is a little ugly.
This line (the definition for the local_build variable) would simplify to be written the same way as the definition of override_arch_ (currently on line 19 of the same file) if the --define change is ok with everyone. I believe that defining this variable (which I arbitrarily named), should not mess with anyone's builds since it is up to the specfile to add logic to use this variable or not, but wanted to ask what others think before making this change

That seems sane to me, I'm not sure if we would need to change any calling scripts in the Adoptium pipelines though. Let's try the change and see if it passes the GH checks and then figure out if there is a caller script in Jenkins that also would need updating.

I added the change and contained it to build.sh since it has an if-statement there anyways (which is a good place to set the flag)

[jmjaffe37]

Same comment as the other PR, please can you add the same support to the /linux/jre directory too

Feature added :)

[karianna]

LGTM - but I wonder if the logic to build locally can be captured more cleanly inside namedd functions / blocks, something like:

function buildLocal() {...}

and checks like

if (isLocal())

[jmjaffe37]

LGTM - but I wonder if the logic to build locally can be captured more cleanly inside namedd functions / blocks, something like:

function buildLocal() {...}

and checks like

if (isLocal())

I'm not fully sure what you mean by this, but maybe I can attempt to explain my original approach here and see if that's what the team might prefer (also not sure if my explanation will make sense in text form here).

Originally in linux/build.gralde, I had a function getLocalBuildStatus() which returns 'true' if an input directory was provided, otherwise false.

Then, in linux/jdk/<debian | redhat>/build.gradle, in the project.exec command: I passed through an additional environment variable buildLocalFlag which was used to determine whether or not to build locally. I decided against this since I could get it to work without reliance across these extra files.