This document covers cover how to perform various repeatable tasks in the repository that might not otherwise be obvious from just looking at the repository.
I wrote this diagram partially for my own benefit in issue 957 that lists the shell scripts (S) and environment scripts (E). I think it would be useful to incorporate this into the documentation (potentially annotated with a bit more info) so people can find their way around the myriad of script levels that we now have.
Note that the "end user" scripts start at makejdk-any-platform.sh and a
diagram of those relationships can be seen here
See the ci-jenkins-pipelines FAQ.md for the Jenkins side of the pipeline
G - make-adopt-build-farm.sh
S - set-platform-specific-configurations.sh
E - sbin/common/constants.sh (DUPLICATED LATER FROM configureBuild.sh)
E - platform-specific-configurations/${OPERATING_SYSTEM}.sh
S - makejdk-any-platform.sh
E - ${SCRIPT_DIR}/sbin/common/config_init.sh (Parse options)
E - ${SCRIPT_DIR}/docker-build.sh (Runs build.sh within container)
E - ${SCRIPT_DIR}/native-build.sh (Runs build.sh natively)
E - ${SCRIPT_DIR}/configureBuild.sh
E - ${SCRIPT_DIR}/sbin/common/constants.sh
E - ${SCRIPT_DIR}/sbin/common/common.sh
E - ${SCRIPT_DIR}/signalhandler.sh (rm container on SIGINT/SIGTERM)
S - {buildOpenJDKViaDocker|buildOpenJDKInNativeEnvironment}There is also some documentation in CHANGELOG.md
- The upstream OpenJDK build requirements are at Supported Build Platforms
- The Temurin levels we build on are in Minimum-OS-levels although anything with comparable equivalent or later C libraries should work OK (in particular we have built on most current Linux distros without issues)
In terms of OSs and compilers, these are what we currently use for each Temurin release:
| JDK | Platform | Build env | Compiler | Other info |
|---|---|---|---|---|
| 8,11,17 | Linux/x64 | CentOS 6 | GCC [1] | glibc 2.12 |
| 20+ | Linux/x64 | CentOS 7 | GCC [1] | glibc 2.17 |
| All | Linux/arm32 | Ubuntu 16.04 | GCC [1] | glibc 2.23 |
| All | Linux/s390x | RHEL 7 | GCC [1] | glibc 2.17 |
| All | Linux (others) | CentOS 7 | GCC [1] | glibc 2.17 |
| 8 | Windows/x64 | Server 2022 | VS2017 - CL 19.16.27049 | |
| 11,17 | Windows/x64 | Server 2022 | VS2019 - CL 19.29.30146 | |
| 21+ | Windows/x64 | Server 2022 | VS2022 - CL 19.37.32822 | |
| 8 | Win32 | Server 2022 | VS2013 - CL 18.00.40629 | |
| 11 | Win32 | Server 2022 | VS2017 - CL 19.16.27049 | |
| 17 | Win32 | Server 2022 | VS2019 - CL 19.29.30146 | |
| All | Macos/x64 | 10.14 (18.7.0) | clang-1001.0.46.4 | |
| All | Macos/aarch64 | 11 (20.1.0) | clang-1200.0.32.29 | There is no build for JDK8 |
| All | Alpine/x64 | 3.15.6 | GCC 10.3.1 | Default compiler Alpine 10.3.1_git20211027 |
| All | Alpine/aarch64 | 3.15.4 | GCC 10.3.1 | Default compiler Alpine 10.3.1_git20211027 |
| 8 | AIX | 7.2 (7200-02) | xlc 13.1.3 (13.01.0003.0007) | |
| 11+ | AIX | 7.2 (7200-02) | xlc 16.1.0 (16.01.0000.0011) | |
| 8 | Solaris (Both) | 10 1/13 | Studio 12.3 (C 5.12) |
[1] - Linux gcc levels are 7.5 for JDK8 and 11, 10.3.0 for JDK17 and 11.2.0 for JDK20+. At present these are all built from us from the upstream GCC sources on our machines as a one off and stored in https://ci.adoptium.net/userContent/gcc/ where they are consumed by our playbooks
All of our machines used for building Temurin are set up using the ansible playbooks from the infrastructure repository.
Runtime platforms are in our supported platforms page.
Where you change them depends on the scope of the parameter or flag:
- If the parameter will affect all users, regardless of environment or OS/Arch
- build.sh OR makejdk-any-platform.sh depending on how high up in the execution stack it needs to be.
- Example PR - Adding a new archival feature for OpenJ9 memory dumps
- If the parameter will affect all machines of a specific OS OR related to the environment set up by our ansible scripts at the shell script level
- Modify the relevant environment files in platform-specific-configurations
- Example PR - Adding a new configure flag for OpenJ9 on all AIX machines
- If the parameter will affect only our jenkins environment or jenkins machine environment
- Modify the pipeline files, although this is normally only done for configuration differences such as OpenJ9 Large Heap builds. See the configuration file documentation for more information about adding or altering custom jenkins param.
- Example PR - Adding Jenkins Support for a Cross Compiled Bisheng Binary
| Parameter Location | Impact |
|---|---|
| build.sh OR makejdk-any-platform.sh | Anyone (including end users) who are running makejdk-any-platform.sh |
| platform-specific-configurations scripts | Those using build-farm/make-adopt-build-farm.sh (inc. our pipelines) - should be stuff specific to our machines |
| Jenkins resources in ci-jenkins-pipelines | Only when run through our jenkins pipelines. See the configuration file documentation for more information |
Since it's quite long, this is covered in a separate RELEASING.md document
If you're making changes ensure you follow the contribution guidelines in CONTRIBUTING.md including running shellcheck if you're modifying the shell scripts.
For more information, see the PR testing documentation.
Smoke tests are quick and simple tests to verify that we 'built the right thing'. They can be found in the buildAndPackage directory Smoke tests verify things like:
- the java -version output is correct
- certain features are available in certain builds (checks for shenandoah GC or xxx)
- the right set of modules are included etc
They use the same mechanisms and automation used by the AQA test suite. This means they can be run on the command-line, or as part of a Jenkins job or in a GitHub workflow. For this repository, they are part of PR testing via the build.yml workflow using the run-aqa action.
They are also run as part of the Jenkins build pipelines (see the runSmokeTests() method in the openjdk_build_pipeline groovy script), triggered after the build is complete and before any AQA tests get run against the build. If smoke tests fail, it likely indicates we built the 'wrong thing' and there is no point running further testing until we resolve the build issues.
To run them on the command-line, one can follow the same general instructions for running any AQA test on the command-line, with the additional step of exporting variables to indicate where to find test material (VENDOR_TEST_REPOS, VENDOR_TEST_BRANCHES, VENDOR_TEST_DIRS). See: SmokeTesting.md
This PR demonstrates changes required to add a new build pipeline param and the associated version/platform job configurations for setting the value when needed (note, the pipelines/ dir has since been moved to our jenkins repository).
The following are the pre-requisites for the the build to be successful
| Dependency | Install command(Linux) |
|---|---|
| libfontconfig1-dev | sudo apt-get install libfontconfig1-dev |
| libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev | sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev |
| libasound2-dev | sudo apt-get install libasound2-dev |
| libcups2-dev | sudo apt-get install libcups2-dev |
After installing the above dependencies, run the following commands from the terminal
Clone temurin-build repository
git clone https://github.com/adoptium/temurin-build.git
Navigate to the root directory of the project
cd temurin-build
Set the variant to temurin
export VARIANT=temurin
export JAVA_TO_BUILD=jdk
The Adoptium build tag you want to build, don't set to build HEAD
export SCM_REF=jdk-20+2_adopt
Set the build to spin on release
export RELEASE=true
Bypass the cache completely by calling the real compiler using ccache
export CONFIGURE_ARGS=--disable-ccache
Trigger the build
build-farm/make-adopt-build-farm.sh
Once the build has successfully completed the built JDK archive artifact will be available in directory:
JDK Archive: workspace/target/jdk-hotspot.tar.gz