Java

This guide provides a walkthrough of .razorops.yaml for a typical Java-based application based. Our CI process is going to consist of following steps:

Choosing a Java version
Install dependencies
Build executable
Running tests and reports
Storing jars or build artifacts

Demo project¶

To get started quickly, you can refer to our sample Java based pipeline configuration here.

Java Version¶

Usually the first step before writing CI spec is to decide the language runtime and support for the version compatible with your application. We support most active versions of Java distributions. You have the following options if you want to pin-down a version of Java/JDK -

For Docker runner environment, you can specify a container image (razorci/openjdk with tag.
For Linux-VM environment, you can use pre-installed or change the version (or install new version if not available) using sdkman.

Selecting Java version in Docker environment

Razorops provide convenience container images for various programming languages. You can use an appropriate image tag to control Java version. Common build tools like maven, sbt, ant and gradle are pre-installed in the container image.

globaltask

global:
  runner: razorci/openjdk:11-buster
...

tasks:
  build-deps:
    runner: razorci/openjdk:11-buster

You can additionally provide environment variables and provide service dependencies to run your test suite.

Selecting Ruby version on Linux-VM environment

In Linux-VM build environment, we use [skdman][https://sdkman.io/jdks] to manage the various Java versions managed by various distributors. You can find currently supported versions in toolbox reference. You can also install a different version using sdk install java <version>-<provider> command if it's not supported by us.

Here are few commands to use, switch and install a version -

    # part of .razorops.yaml file
    steps:
    - commands:
      # list installed versions
      - sdk list java

      - javac --version

      - sdk use java 17.0.12-amzn
      - javac --version

      # install Java 23 (OpenJDk)
      - sdk install java 23-open

      - sdk use java 23-open
      - java --version
      # openjdk 23 2024-09-17
      # OpenJDK Runtime Environment (build 23+37-2369)
      # OpenJDK 64-Bit Server VM (build 23+37-2369, mixed mode, sharing)

Note

Available Java/JDK versions pre-installed via sdkman - 11.x and 17.x (JDK managed by Amazon - Corretto).

Download dependencies¶

Downloading java third-party packages/dependencies from the internet can be time-consuming, you can greatly speed up this process by caching it using an unique key. In future workflow runs, the cache will be restored so that dependencies don't need to be downloaded from remote (Maven, Ant, Gradle etc) repositories. For more information, see Caching dependencies.

mavengradle

tasks:
  build-deps:
    runner: razorci/openjdk:11-buster
    steps:
    - checkout
    - cache/pull:
        key: maven-repo-{{ checksum "pom.xml" }}
        fallback_key: maven-repo-

    - run: mvn -q clean package
    ...
    - cache/push:
        key: maven-repo-{{ checksum "pom.xml" }}
        paths:
        - ~/.m2

tasks:
  build-deps:
    runner: razorci/openjdk:11-buster
    steps:
    - checkout
    - cache/pull:
        key: gradle-repo-{{ checksum "build.gradle" }}
        fallback_key: gradle-repo-

    - run: gradlew assemble
    ...

    - cache/push:
        key: gradle-repo-{{ checksum "build.gradle" }}
        paths:
        - ~/.gradle

Execute tests¶

You can use the same commands that you use locally to test your code and generate JUnit reports to tell how much of your application is tested.

An example below uses Maven to execute tests, generate JUnit and coverage reports using surefire or failsafe library.

tasks:
  build-deps:
    runner: razorci/openjdk:11-buster
    steps:
    ...
    - run: mvn clean test
    ## or
    - run: mvn surefire-report:report
    ...
    - reports/junit: 
      - target/surefire-reports/TEST-*.xml
      - target/failsafe-reports/TEST-*.xml

The JUnit reports are parsed and ingested to show insights in Dashboard so that you don't have to look into logs for an error or a flaky test-case. For more information, see "Test Insights"](#).

Test measurement helps in identifying and minimizing bugs and design defects in your code.

Generate coverage report¶

Code coverage is a measure of how much of your code executes when the automated tests run. It helps to gauge the quality of tests and the maintainability of source code. Jacoco, Cobertura and Emma are some of the popular libraries for Java code coverage. Below is an example:

.razorops.yamlpom.xml

tasks:
  unit-test:
    runner: razorci/openjdk:11-buster
    steps:
    ...
    - run: mvn test # run the actual tests and generate report
    # or
    - run: mvn jacoco:report
    ...
    - reports/html:
        dir: target/site/jacoco

<project xmlns="http://maven.apache.org/POM/4.0.0">
  ...
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      ..
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.8.3</version>
      </plugin>
      ...
    </plugins>
  </build>
</project>

Publish artifacts¶

You can upload artifacts to view after a workflow completes. For example, you may need to save compiled jars, log files, core dumps, test results, or screenshots. For more information, see "Persisting workflow data using artifacts.".

The below example demonstrates how you can use the artifacts/push step to archive a compiled "uberjar" file from running mvn package command. For more information, see the artifacts/push step.

tasks:
  unit-test:
    steps:
    ...
    - commands:
      - mvn dependency:go-offline # gets the project dependencies
      - mvn package # run the actual tests

    ...
    - artifacts/push:
        name: demo-0.0.1.jar
        paths: [target/demo-java-spring-0.0.1-SNAPSHOT.jar]