DOCSEARCHbyAlgolia
Submit Docs

adoptium/temurin-build

repository·master·Indexed 22 days ago

https://github.com/adoptium/temurin-build

Scripts and infrastructure for building OpenJDK binaries optimized for Eclipse Temurin™. Includes the makejdk-any-platform.sh entry point for native, Docker, and Podman builds, support for multiple build variants (hotspot, openj9, etc.), and tools for generating CycloneDX Software Bill of Materials (SBoM).

Tokens
14.1K
Snippets
28
Records
58
Agent score
76%

What's inside temurin-build

  1. Overview of repository structure

    master

    The repository is organized into several functional directories:

    • sbin/: Contains the core Temurin build scripts. build.sh is the primary entry point, often invoked by native-build.sh, docker-build.sh, or makejdk-any-platform.sh.
    • docker/: Contains tools for generating Dockerfiles for OpenJDK builds.
    • build-farm/: Shell scripts used by Jenkins for multi-configuration Adoptium OpenJDK binary builds.
    • security/: Contains the cacerts file and scripts used to bundle security certificates into the JDK to enable SSL connections.
    • pipelines/: (Moved to a separate repository) Jenkins pipelines.
    • git-hg/: (Moved to a separate repository) Mirroring scripts.

  2. What is the OpenJDK Vulnerability Group?

    master
    The OpenJDK Vulnerability Group is a private group of trusted individuals responsible for receiving vulnerability reports in the OpenJDK codebase. They work to resolve these vulnerabilities and ensure they are integrated into official releases in a timely manner.

  3. What are smoke tests and how to run them

    master

    Smoke tests are quick checks to verify that the build produced the correct artifacts (e.g., verifying java -version output, checking for specific features like Shenandoah GC, or ensuring correct module inclusion). They are located in the test/functional/buildAndPackage directory.

    Running Smoke Tests:

    • In CI: They run automatically via GitHub workflows (build.yml) or Jenkins pipelines after the build completes but before full AQA testing.
    • Locally: You can run them via the command line following the AQA test execution patterns. You must export variables to point to test materials:
      • VENDOR_TEST_REPOS
      • VENDOR_TEST_BRANCHES
      • VENDOR_TEST_DIRS

    Refer to SmokeTesting.md for detailed command-line instructions.

  4. Use comparable_patch.sh to compare different Vendor JDKs

    master

    The comparable_patch.sh tool allows you to compare two different Vendor JDK builds (e.g., comparing Eclipse Temurin to another vendor) that were built from the same source but differ only by branding.

    The patching process performs the following:

    • Expands zips and jmods.
    • Removes signatures (Windows & macOS).
    • Neutralizes VS_VERSION_INFO Vendor strings (Windows).
    • Removes non-comparable CRC generated UUID values (Windows & macOS).
    • Removes Vendor strings from executables, classes, and text files.
    • Removes module-info differences caused by signed module hashes.
    • Removes non-deterministic artifacts like Manifest Created-By stamps.
    • Zeros out CRC in .gnu_debuglink ELF sections.

    CRITICAL WARNING: If you run comparable_patch.sh, do not use repro_compare.sh for the final comparison, as it will cause false negatives due to double-preprocessing. Instead, use diff -r or run repro_compare.sh with the flag PREPROCESS=no.

  5. Understand the OpenJDK release models

    master

    OpenJDK releases follow different maintenance patterns depending on whether they are managed by non-Oracle maintainers (like Red Hat) or by Oracle. Understanding these models is necessary for knowing how updates and vulnerability fixes are integrated.

    Non-Oracle (e.g., Red Hat) maintained updates

    Maintainers work on quarterly updates in a head stream (e.g., jdk11u). Fixes for the next update are developed in a dev stream (e.g., jdk11u-dev).

    • Regular builds: Tagged weekly (e.g., jdk-11.0.5+6).
    • GA (General Availability): On GA day, fixes from the OpenJDK Vulnerability Group are merged into the final build, which is then tagged (e.g., jdk-11.0.5-ga).

    Oracle Managed updates

    Oracle manages the most recent JDK release updates. For a specific version, Oracle typically produces two updates (e.g., jdk-13.0.1 and jdk-13.0.2).

    • Internal Work: Updates and Vulnerability Group fixes are managed internally and are not public until the GA date.
    • GA (General Availability): On GA day, Oracle merges internal branches and Vulnerability Group fixes to produce the final tagged GA build (e.g., jdk-13.0.1-ga).
    • LTS vs. STS: For Short Term Support (STS) releases, there are no further releases after the two Oracle updates. For Long Term Support (LTS) releases, the OpenJDK community takes over subsequent maintenance in public streams.

  6. Understand Solaris build and test proxy jobs

    master

    Because Jenkins agents require Java 17+ and no such JVM is available for Solaris 10 (x64 and SPARC), Solaris builds and tests are performed via "proxy" jobs. These jobs run on xLinux machines (labeled solaris&&buildproxy for builds and solaris&&testproxy for tests) that use ssh to control the actual Solaris target machines.

    Build Pipeline Structure

    For Solaris, the -simplepipe pipeline orchestrates the process:

    1. Build: Invokes the -simple build job.
    2. Sign SBOM: sign_sbom_jsf stage.
    3. Sign GPG: sign_temurin_gpg stage.
    4. Test: Invokes the -simpletest job.
    5. Release: Standard release stage.

    Build Job Mechanism

    The -simple build job:

    • Runs on an xLinux agent (e.g., dockerhost-azure-solarisproxy).
    • Uses ssh to clone temurin-build onto the Solaris target.
    • Executes make-adopt-build-farm.sh on the target.
    • Uses scp to pull workspace/target contents back to the proxy machine.
    • Generates sha256.txt, a metadata file, and filenames.txt (used by the test job to identify artifacts).

  7. Understand the PR Tester workflow

    master

    The openjdk-build project uses automated testing jobs, colloquially known as "The PR Tester," to ensure code changes do not break existing functionality. These tests are executed automatically on every Pull Request (PR) via GitHub Actions workflows defined in the .github/workflows directory.

    There are two primary test groups:

    1. Linter: Analyzes changes for conformance to writing and coding standards.
    2. Build: Executes full JDK builds across a matrix of Java versions, operating systems, and VM variants to mimic local or Jenkins-based build environments.

  9. How the Lockdown Period works during Temurin releases

    master

    During the week before a release, a 'Lockdown period' is enforced to prevent destabilization.

    Repository Status

    • master branches under lockdown: github-release-scripts, containers, installer, and mirror-scripts.
    • Open for work: temurin-build, ci-jenkins-pipelines, and jenkins-helper (though their release branches are under code-freeze management).

    Procedure for Critical Fixes

    If a PR is required during lockdown, it must be a 'critical' fix (e.g., preventing a build break). To request a merge:

    1. Add a comment to the PR: "Approval to merge during the lockdown cycle please" and post in the appropriate Slack channel.
    2. Post a note in the Slack channel with a link to that comment.
    3. The comment must have approval from at least one build committer and one PMC member.
    4. The PR can be merged after a 2-hour delay following the Slack post to allow for objections, unless the delay would cause a breakage.

    Alternatively, in the Slack release channel, post: "Requesting approval to merge during the lockdown period. Please thumbs up the comment to approve". If two committers express approval, the change can be merged.

  10. Planned CycloneDX Formulation Support

    master

    Future updates to TemurinGenSBOM aim to implement CycloneDX formulation support. This will allow the SBoM to describe how OpenJDK is built with Temurin, rather than just listing components.

    When the --formulation option is implemented, it will output a CycloneDX-compliant description (following the CycloneDX 1.6 spec) including:

    • The Docker image used
    • Host/container workspace setup
    • Environment variables
    • Source retrieval via Git
    • Execution of the build script
    • Additional flags and configurations

  11. How CycloneDX SBoM generation works in Temurin

    master

    The Temurin project generates Software Bill of Materials (SBoM) in the CycloneDX format. The generation process integrates shell scripts with Java code to bridge the build environment and the CycloneDX API.

    Workflow:

    1. Trigger: The build must be initiated with --create-sbom added to the BUILD_ARGS.
    2. Execution: At the end of the build, generateSBoM is called within build.sh.
    3. Data Collection: sbom.sh locates required build information and uses helper methods to prepare the data.
    4. SBoM Update: These helpers invoke the TemurinGenSBOM Java class, passing the SBoM file path and a specific action. TemurinGenSBOM then appends the appropriate sections to the SBoM file.

  12. Understand the Temurin build automation script hierarchy

    master

    The build automation is organized into multiple layers of shell scripts (S) and environment scripts (E). End users typically interact with the scripts starting at makejdk-any-platform.sh.

    Script Hierarchy Overview:

    • make-adopt-build-farm.sh (G): Top-level generator.
    • set-platform-specific-configurations.sh (S): Configures platform details.
    • platform-specific-configurations/${OPERATING_SYSTEM}.sh (E): OS-specific environment settings.
    • makejdk-any-platform.sh (S): The primary entry point for end users.
    • sbin/common/config_init.sh (E): Parses options.
    • docker-build.sh (E): Runs build.sh inside a container.
    • native-build.sh (E): Runs build.sh natively.
    • configureBuild.sh (E): Orchestrates the build process, calling sbin/common/constants.sh, sbin/common/common.sh, and signalhandler.sh.