Moving from Travis CI to GitHub actions
For our first two years we were very happy Travis CI users. We had chosen Travis because it had a dead simple config file and it just worked. Then it didn’t anymore.
This short post will show you how to move from a basic Travis CI setup to a GitHub actions setup.
The old Travis setup
For a long time, this is how the config file looked:
language: java jdk: - openjdk8 - openjdk9 - openjdk10 - openjdk11 - openjdk12
This worked great at first, but after a year it started to become very flaky. When we finally moved away from Travis, this is how our config file looked:
sudo: required # this became required on 30-08-2018 for unknown reasons language: java jdk: - openjdk8 #- openjdk9 #- openjdk10 - openjdk11 #- openjdk12 cache: directories: - $HOME/.m2
Builds would take up to 30 minutes, and Travis would fail to install some of the JDKs half the time. As you can see, we had to disable most of the JDKs to mitigate the time spent retriggering builds.
Sometimes Travis would download dependencies at 200 bytes/s. We tried to cache the
to mitigate this, but it didn’t really help too much.
It’s not that our needs outgrew Travis, their product just stopped working.
The new GitHub actions setup
Our GitHub actions setup is a bit more verbose, but it’s a lot faster and more deterministic than Travis.
Unlike Travis, GitHub actions also supports Windows, so that’s nice.
Javalin is now built on MacOS, Ubuntu and Windows, for Java 8 to 13.
name: Java CI on: [push, pull_request] jobs: build: runs-on: $ strategy: fail-fast: false matrix: java_version: [1.8, 9, 10, 11, 12, 13] os: [windows-latest, macOS-latest, ubuntu-latest] steps: - name: Checkout uses: actions/[email protected] - name: Set up JDK $ uses: actions/[email protected] with: java-version: $ - name: Make Maven Wrapper executable if: contains(matrix.os, 'win') == false run: chmod +x ./mvnw - name: Build with Maven run: ./mvnw package --file pom.xml
That’s pretty much it. The only downside to GitHub actions we’ve seen so far is that you can’t retrigger individual builds.
For example, if
macOS-latest jdk13 fails, you need to re-run the entire test matrix.
The only failed builds we’ve seen have been due to our own bad tests though, so it’s not really an issue.
If you have a simple Travis setup, we highly recommend the switch.