cimg/openjdk pulls statistics

CircleCI Convenience Images => OpenJDK

A Continous Integration focused OpenJDK / Java Docker image built to run on CircleCI

*This image is designed to supercede the legacy CircleCI OpenJDK image, circleci/openjdk.*

cimg/openjdk is a Docker image created by CircleCI with continuous integration builds in mind. Each tag contains a version of OpenJDK, the Java Development Kit and any binaries and tools that are required for builds to complete successfully in a CircleCI environment.

Table of Contents

• Getting Started • How This Image Works • Development • Contributing • Additional Resources • License

Getting Started

This image can be used with the CircleCI docker executor. For example:

In the above example, the CircleCI OpenJDK Docker image is used for the primary container. More specifically, the tag 15.0 is used meaning the version of OpenJDK will be v15.0.2. You can now use OpenJDK within the steps for this job.

How This Image Works

This image contains the Java programming language packaged as OpenJDK by Adoptiumn.

Variants

Variant images typically contain the same base software, but with a few additional modifications.

Node.js

The Node.js variant is the same OpenJDK image but with Node.js also installed. The Node.js variant can be used by appending -node to the end of an existing cimg/openjdk tag.

Browsers

The browsers variant is the same OpenJDK image but with Node.js, Selenium, and browser dependencies pre-installed via apt. The browsers variant can be used by appending -browser to the end of an existing cimg/openjdk tag. The browsers variant is designed to work in conjunction with the CircleCI Browser Tools orb. You can use the orb to install a version of Google Chrome and/or Firefox into your build. The image contains all of the supporting tools needed to use both the browser and its driver.

Tagging Scheme

This image has the following tagging scheme:

- The version of OpenJDK to use. This can be a full SemVer point release (such as 11.0.10) or just the minor release (such as 11.0). If you use the minor release tag, it will automatically point to future patch updates as they are released by Adoptium & Oracle. For example, the tag 11.0 points to OpenJDK v11.0.10 now, but when the next release comes out, it will point to OpenJDK v11.0.11.

[-variant] - Variant tags, if available, can optionally be used. For example, the Node.js variant could be used like this: cimg/openjdk:15.0-node.

Development

Images can be built and run locally with this repository. This has the following requirements:

• local machine of Linux (Ubuntu tested) or macOS • modern version of Bash (v4+) • modern version of Docker Engine (v19.03+)

Cloning For Community Users (no write access to this repository)

Fork this repository on GitHub. When you get your clone URL, you'll want to add --recurse-submodules to the clone command in order to populate the Git submodule contained in this repo. It would look something like this:

If you missed this step and already cloned, you can just run git submodule update --recursive to populate the submodule. Then you can optionally add this repo as an upstream to your own:

Cloning For Maintainers ( you have write access to this repository)

Clone the project with the following command so that you populate the submodule:

Generating Dockerfiles

Dockerfiles can be generated for a specific OpenJDK version using the gen-dockerfiles.sh script. For example, to generate the Dockerfile for OpenJDK v11.0.5, you would run the following from the root of the repo:

The generated Dockerfile will be located at ./11.0/Dockefile. Unlike most of the CircleCI Convenience Images, the OpenJDK image requires not only the version number to be passed but the Adoptium download URL as well. This is due to inconsistencies with the extra build number they add to their version numbers, which doesn't fit the SemVer scheme. To build this image locally and try it out, you can run the following:

Building the Dockerfiles

To build the Docker images locally as this repository does, you'll want to run the build-images.sh script:

This would need to be run after generating the Dockerfiles first. When releasing proper images for CircleCI, this script is run from a CircleCI pipeline and not locally.

Publishing Official Images (for Maintainers only)

The individual scripts (above) can be used to create the correct files for an image, and then added to a new git branch, committed, etc. A release script is included to make this process easier. To make a proper release for this image, let's use the fake OpenJDK version of OpenJDK v9.9.9 and a fake release URL, you would run the following from the repo root:

This will automatically create a new Git branch, generate the Dockerfile(s), stage the changes, commit them, and push them to GitHub. The commit message will end with the string [release]. This string is used by CircleCI to know when to push images to Docker Hub. All that would need to be done after that is:

• wait for build to pass on CircleCI • review the PR • merge the PR

The main branch build will then publish a release.

Incorporating Changes

How changes are incorporated into this image depends on where they come from.

build scripts - Changes within the ./shared submodule happen in its own repository. For those changes to affect this image, the submodule needs to be updated. Typically like this:

parent image - By design, when changes happen to a parent image, they don't appear in existing OpenJDK images. This is to aid in "determinism" and prevent breaking customer builds. New OpenJDK images will automatically pick up the changes.

If you *really* want to publish changes from a parent image into the OpenJDK image, you have to build a specific image version as if it was a new image. This will create a new Dockerfile and once published, a new image.…

Description from the Docker Hub listing.