Using Oracle’s JDK in CircleCI (with Gradle)

I’m evaluating re-writing Dashman in Java (instead of Electron). It’s too early to tell, but so far all the experiments and the early re-write are going well and it’s solving the issues I was having with Electron. This short post is about CircleCI.

Because now I’m using common, boring technologies, I decided setting a CI was going to be easy enough that I didn’t mind doing it and I chose CircleCI, mostly because of their free plan.

Sadly, my project didn’t work out of the box. JavaFX was nowhere to be found. The reason was that CircleCI uses OpenJDK instead of the Oracle’s JDK by default. I guess that’s enough for the vast majority of people. Switching to Oracle’s JDK was not hard, but I couldn’t find a straightforward post, so, this is it.

CircleCI gives you a configuration example that contains something like this:

version: 2
  jobs:
    build:
      docker:
        # specify the version you desire here
        - image: circleci/openjdk:8-jdk

I’m not very familiar with Docker and how CircleCI uses, all I know is that it’s a container system for, essentially, operating system images. CircleCI has a repo of Docker images and the one that include’s Oracle’s JDK is called circleci/jdk8. What comes after the colon in the config is the version of the Docker image (I think) which Docker calls tags and for this one, at the time of this writing, there was 0.1.1 but you can easily check the latest one here: https://hub.docker.com/r/circleci/jdk8/tags/

With that in mind, the config should now look like this:

version: 2
  jobs:
    build:
      docker:
        # specify the version you desire here
        - image: circleci/jdk8:0.1.1

And that’s it… well, unless you are using Gradle. That image doesn’t provide Gradle, so, you need to replace all the mentions of gradle with gradlew and use the wrapper that should be part of your repo. But before that will work, you need to make that file executable on the CircleCI server by calling chmod +x gradlew on it. The resulting config file for me looks like this:

# Java Gradle CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-java/ for more details
#
version: 2
jobs:
  build:
    docker:
      # specify the version you desire here
      - image: circleci/jdk8:0.1.1

      # Specify service dependencies here if necessary
      # CircleCI maintains a library of pre-built images
      # documented at https://circleci.com/docs/2.0/circleci-images/
      # - image: circleci/postgres:9.4

    working_directory: ~/repo

    environment:
      # Customize the JVM maximum heap limit
      JVM_OPTS: -Xmx3200m
      TERM: dumb

    steps:
      - checkout
      - run: chmod +x gradlew

      # Download and cache dependencies
      - restore_cache:
          keys:
          - v1-dependencies-{{ checksum "build.gradle" }}
          # fallback to using the latest cache if no exact match is found
          - v1-dependencies-

      - run: ./gradlew dependencies

      - save_cache:
          paths:
            - ~/.m2
          key: v1-dependencies-{{ checksum "build.gradle" }}

      # run tests!
      - run: ./gradlew test

And that’s it, that worked.

Advertisements

Setting (database) credentials on a Spring Boot project, the right way

Searching online for how to set up the credentials to access the database (or any other service) while in development leads to a lot of articles that propose something that works, but it’s wrong: putting your credentials in the application.properties file that you then commit to the repository.

The source code repository should not have any credentials, ever:

  • You should be able to make your project open source without your security being compromised.
  • You should be able to add another developer to your team without them knowing any credentials to your own development machine.
  • You should be able to hire a company that does a security analysis of your application, give them access to your source code and they shouldn’t gain access to your database.
  • You should be able to use a continuous integration service offered by a third party without that third party learning your database credentials.

If you want to see what happens when you commit your credentials to your repo, check out these news articles:

That’s probably enough. I hope I convinced you.

In an effort to find a solution for this, I asked in Stack Overflow and I got pointed in the right direction.

Leave application.properties where it is, in your resources of code folder, commit it to the repository. Instead, create a new file in ${PROJECT_ROOT}/config/application.properties and also add it to your version control ignore file (.gitignore, .hgignore, etc). That file will contain the credentials and other sensitive data:

# This should be used only for credentials and other local-only config.
spring.datasource.url = jdbc:postgresql://localhost/database
spring.datasource.username = username
spring.datasource.password = password

Then, to help onboard new developers on your project (or yourself in a new computer), add a template for that file, next to it. Something like ${PROJECT_ROOT}/config/application.template.properties that will contain:

# TODO: copy this to application.properties and set the credentials for your database.
# This should be used only for credentials and other local-only config.
spring.datasource.url = jdbc:postgresql://localhost/database
spring.datasource.username = 
spring.datasource.password = 

And voila! No credentials on the repo  but enough information to set them up quickly.

Disclaimer: I’m new to Spring Boot, I only started working with it a few days ago, so, I may be missing something big here. If I learn something new that invalidates this post, I’ll update it accordingly. One thing I’m not entirely sure about is how customary it would be to have ${PROJECT_ROOT}/config/application.properties on the ignore list. Please, leave a comment with any opinions or commentary.