Initial Commit Of New Installer Automated Build Process.

[steelhead31]

This PR includes the code needed to automate the production of the linux installer packages in jenkins:

The production version of this job is here : https://ci.adoptium.net/job/build-scripts/job/release/job/create_installer_linux/

It is triggered as a post build action by the release job, that publishes the release tarballs to the GitHub binary repos. ( https://ci.adoptium.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/ )

Process Overview:

The refactor release job above is triggered when the testing for a release is complete, and triggered from the release pipeline e.g ( https://ci.adoptium.net/job/build-scripts/job/release-openjdk17-pipeline/85/ )

The parameters utilised for this job from the publish links in the pipeline output, are then passed into the new create installer linux job

The above job will then create the relevant packages on a per version, architecture and platform ( linux or alpine linux ). 

Once the above process completes successfully, a downstream job will publish an archive containing the generate rpm specfiles, alpine apkbuild file or debian ( control, changelog and rules ) files which have been dynamically generated as part of the package build. The downstream job triggered is referenced in the pipeline for the create installer linux job, and is called publish_linux_pkg_src.   The downstream job published the pkg source files to version numbered releases in the following binary repo. https://github.com/adoptium/temurin-linux-pkg-sources

Development process in jenkins here : https://ci.adoptium.net/job/sfr-build-linux-package-modular/

Epic Link : #1005

See Also:

#1019
#1037
#1049
#1069
#1045
#1072
#1080
#1094

[jiekang]

Can all the relevant GH issues be referenced here? It doesn't have to be the Resolves/Closes text.

[sxa]

I've added a few comments within the code - some of them are just suggestions, others stuff for the future. I haven't verified the technicaly functionality/command lines etc. or the template files at this time since I would expect any issues with those to have come out during your testing, but I may look at that later :-) A few overall comments:

• This file is rather big!
• You've got echo lines at the start of each phase. It would be good to have an "eyecatcher" prefix on each of those e.g. installer_stage: blah to be able to find the parts of the log, and potentially use it to extract timings. This is similar to build.sh : and openjdk_build_pipeline: (I think that's the right one!) that's in the build logs
• I've made a couple of comments about indents in here when they jumped out at me, but the whole file probably just needs to have that checked before we commit it.
• It may not make sense to try and change this, but for anyone else reviewing this we have quite a few different names of some of the variables e.g. arch vs PARCH vs packagearch vs packagearch{Deb,Rhel} vs {RHEL,SUSE}architecture and I wonder if we could have more uniformity in the naming of those.
  As I mentioned before the comments on the doc were made before I realised that was unchanged from the original, so feel free to disregard them for now (unless you're using those as the basis for new doc!)

[github-actions]

A block has been put on this Pull Request as this repository is temporarily under a code freeze due to an ongoing release cycle.

If this pull request needs to be merged during the release cycle then please comment /merge and a PMC member will be able to remove the block.

If the code freeze is over you can remove this block by commenting /thaw.

[gdams]

I'm not going to block this PR as it's clear that you've put a significant amount of work into this. My only concern is that I see a lot of J2 template files which feel duplicated in places and I wonder if we should centralise this. That said, this doesn't have to be done as part of this PR but I'd like us to keep this as an end goal if possible

[steelhead31]

I'm not going to block this PR as it's clear that you've put a significant amount of work into this. My only concern is that I see a lot of J2 template files which feel duplicated in places and I wonder if we should centralise this. That said, this doesn't have to be done as part of this PR but I'd like us to keep this as an end goal if possible

Thanks @gdams I'll add a note to the EPIC to improve this element. The EPIC is tracking the future plans for improving this process beyond the initial automation attempt.