From ce70090c30f8b73ba06c0ef81770b19389f298cb Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Thu, 20 Jun 2024 11:25:33 +0100 Subject: [PATCH] Add generator doc links Signed-off-by: Stewart X Addison --- README.md | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 206cea1e6..c580a1622 100644 --- a/README.md +++ b/README.md @@ -146,7 +146,9 @@ which are reponsible for running the build using and initiating the tests and other jobs against the completed build if successful. A "Smoke Test" job such as [jdk21u-linux-aarch64-temurin-SmokeTests](https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk21u/job/jdk21u-linux-aarch64-temurin_SmokeTests/) -(TODO: Links to info about what that contains) which is initiated after the +which is similar to our test jobs but runs the tests from the temurin-build +[buildAndPackage directory](https://github.com/adoptium/temurin-build/tree/master/test/functional/buildAndPackage) +which is initiated after the build perfoms some basic tests against the build artefacts and acts as a gate to kicking off the subsequent steps. Once complete, the openjdkXX-pipelines which run the early access builds will generally invoke @@ -156,9 +158,9 @@ the jobs to publish them as a release in github (e.g. ## Job generation As you can see from the above sections, there are a lot of separate jobs in -jenkins which are used during the build process. These are not created -manually, but are autogenerated using the generator pipelines. TODO: More -information on this is at ... +jenkins which are used during the build process. Since there are so many of +them, these are not created manually, but are autogenerated using an +automatic generator process. The top level [build-pipeline-generator](https://ci.adoptium.net/job/build-scripts/job/utils/job/build-pipeline-generator/) @@ -170,8 +172,9 @@ jobs which use [build_job_generator.groovy](pipelines/build/regeneration/build_job_generator.groovy) to generate the subjobs for each platform/variant combination. Both of these pipelines are triggered on a change (PR merge) to the -ci-jenkins-pipelines repository - +ci-jenkins-pipelines repository. They will pause themselves if a pipeline is +not running so as to avoid interfering with a currently executing pipeline. +T Similarly there is an evaluation-pipeline-generator and evaluation-pipeline_jobs_generator_jdkXX for generating the evaluation jobs, a trestle-pipeline-generator for those jobs, plus release-pipeline-generator @@ -179,15 +182,19 @@ andand release_pipeline_jobs_generator_jdkXX for release jobs (the release generators are not triggered automatically but are re-run manually at certain points during each release cycle -The generators make use of files in -[pipelines/jobs/configurations](https://github.com/adoptium/ci-jenkins-pipelines/tree/master/pipelines/jobs/configurations) -and you can see more details of the format in the README.md in that location: +The following is a brief summary of how the generation jobs work but more +details can be found in the +[generator documentation](pipelines/build/regeneration/README.md) + +The generators make use of the following files in +[pipelines/jobs/configurations](pipelines/jobs/configurations). The README +file in that directory contains more details of the configuration format: + - The `jdkXX.groovy`, `jdkXX_evaluation.groovy`, `jdkXX_release.groovy` to determine which platforms to configure and generate for each version. - The individual platform configurations, such as jenkins labels, are defined by `jdkXX_pipeline_config.groovy` files. For more details on the regeneration process overall see the -[regeneration documentation](https://github.com/adoptium/ci-jenkins-pipelines/blob/master/pipelines/build/regeneration/README.md) -and for more detail on the configuration files see this readme +[regeneration documentation](pipelines/build/regeneration/README.md) ## Metadata files generated with each build