Task: Update Workflow to Support Any Java Version Using SDKMAN #27998
Labels
Comments
spbolton
changed the title
spbolton
changed the title
|
The existing changes were focused on the maven build and docker image and not to complete the changes to the github workflows. This top level issue should have have been closed and probably should have been separated into two separate steps |
3 tasks
3 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Jul 15, 2024
This change combines and removes a lot of common functionality and steps
in our workflow process making the whole thing easier to understand and
work with. Our main workflow relies on an initial maven build step that
generates artifacts that can be then pulled in and used in subsequent
test, deploy and release steps. We do this to allow these test stages to
be run in parallel and we can then aggregate the results. To achieve
this we need to use consistent naming conventions for the artefacts and
to provide artefacts and caches that enable the steps to run quickly
without redoing work. There are therefore common steps that we needed to
add to each job and the amount of duplication of these steps causes many
issues to understand or to make consistent changes system-wide. To use
common DRY principles we can pull out these common functionalities into
separate functions (GitHub composite actions) that allow for consistent
behavior.
Part of the push for this are:
1. In moving to Java 21 we want a consistent way to set the Java version
to use by default across the build, whether a major build or a minor
java version without having a mix of versions.
2. Some caches have not been consistently used throughout the build
requiring the config for cache load and save to be the same, and to know
when we should save vs load caches.
### Proposed Changes
* Create setup-java composite action handling all java installation
using sdkman.
* allow override of java version
* specify if graalvm is required (for native builds)
* uses default grallvm 21.0.2-graalce, but enables override from a
parameter
* merge separate cleanup-runner actions into a single action that covers
multiple OS
* create prepare-runner composite action handling common tasks for all
runners
* option to setup master branch reference
* option to cleanup runner
* setup java by default but option to not
* create maven-job composite action providing common functionality to
all workflow steps running maven tasks
* Handle setup native builds
* Handle License if required for step
* Control of caches, maven, nodejs ( node cache restore can be disabled
if no node build steps are required )
* Generate or pull in artifacts to use between initial build and
subsequent steps e.g. .m2/repository
* generation and restore of docker image artifacts
* Handle build report artifact generation automatically using naming
convention
* Flag to say that test results are generated and creation of report
artifact using naming convention
* Use .sdkmanrc as default for obtaining jvm to use in runner
* Update workflows and reusable workflows to use updated composite
actions
* Fix mac os runners (do not use -latest versions that could change )
x86 build not using x86 runner. Sdkman uses version appropriate for the
architecture it is running on.
* Combine 2 stage "validate" profile into single build and validate, fix
validate steps and ordering.
* pull release runner jar from artifacts created in Initial Build and
stored in .m2/repository artifact
* Changes to support use of common build steps with a non snapshot
version that can be commited to .mvn/maven.config
* supports locally created docker image to use release tag not just
snapshot
* Safety check to ensure that PR cannot be commited with
.mvn/maven.config as this should only be created in the release process.
* Protection added to ensure the initial build does not update source
files that have not been committed with the PR. This prevents issues
where other developers merge from master and end up with uncommitted
changes without any code changes of their own.
* Adds generation of .nvmrc file in project root to set the defaults at
the project level like .sdkmanrc.
* Note: .nvmrc file is generated from values in the
nodejs-parent/pom.xml file whereas .sdkmanrc is currently the manually
updated source file used within the build. We may want to choose which
direction is best for both. The protection in initial build for changed
files during build will prevent the .nvmrc file from being merged that
does not match the version defined in Maven in case someone manually
edits the file or does not run a build after modifying the version in
the pom file
Example usage of maven-job
```
- uses: ./.github/actions/maven-job
with:
stage-name: "Build Native Image ${{ matrix.label }}"
maven-args: "package -Pnative -Pdist -DskipTests=$SKIP_TESTS -pl :dotcms-cli"
native: true
generates-test-results: false
artifacts-from: ${{ env.ARTIFACT_RUN_ID }}
version: ${{ inputs.version }}
```
This resolves multiple issues
#28736
#27998
and combines the changes in #28916
### Checklist
- [ ] Tests
- [ ] Translations
- [ ] Security Implications Contemplated (add notes if applicable)
### Additional Info
Tests of post PR workflows have been done on https://github.com/dotCMS/core-workflow-test including Master Checks, dotCLI Release
### Screenshots
Original | Updated
:-------------------------:|:-------------------------:
** original screenshot ** | ** updated screenshot **
This was referenced Jul 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Objective: Modify the GitHub workflows to support any Java version specified in the
.sdkmanrcfile, ensuring consistency across the build and runtime environments.Background
Currently, Java 11 is hardcoded in multiple places within the GitHub workflows and code. This setup requires manual updates to change Java versions, which is cumbersome and error-prone. Additionally, there are discrepancies between the Java versions used for compiling, building, and running the application.
To address these issues, we will:
.sdkmanrcfile is used consistently across all environments.Steps
Change the
java-baseDocker image to use SDKMAN.sdkmanrcfile.Create
setup-mavenshared composite action.sdkmanrcfile to determine the Java version and implementation.Update GitHub workflows
.sdkmanrcfile.setup-mavencomposite action in all relevant workflows.Testing and Validation
.sdkmanrcfile.Checklist
java-baseDocker image to use SDKMAN.setup-mavenshared composite action for Java setup and caching.setup-mavenaction and dynamically set Java version.Additional Notes
The text was updated successfully, but these errors were encountered: