Skip to content

Clean up CI - PR Action #1746

@TomGranot

Description

@TomGranot

This is more of a braindump of experimenting with GitHub Actions for the repo than anything else.

Current Situation

The repo currently uses Tavis-CI (.org) as its CI server, and there's a rumor going round that they would force us to migrate to the closed version of Travis-CI (.com) soon, and with limited build credits to boot (meaning we'd have to have "mandatory downtime", where PRs in the repo are not built each month until the credits replenish).

Edit- Not just a rumor:

https://imgur.com/a/w9v3lcz

That means it's time to jump ship and move to something else. This being an open-source project hosted on GitHub, and with all the nice things I'm hearing about Actions (by GitHub, mostly, but still) looks like their solution is worth a shot.

The current CI does three main things:

  • Build & Test the project
  • Creates documentation for the project
  • Publishes to MavenCentral if master is being built

For the first two, I think the relevant "Build Java With Maven" GitHub Actions Docs should suffice.

For the third part, there's actually a dedicated Github Actions way to publish to Maven Central, that might absolve us from using the current hack.

Game plan

I think I'll just start messing around on a private fork to see how things go. Still blocked by not having the Sonatype release key yet (pending over at the Sonatype JIRA), but I can probably get the pipeline up until that step and then plug in the credentials.

The CI still needs a lot of work (it's very barebones right now), but I'd just like to finish the migration and think about all that jazz later.

One interesting thing to I should explore, though, is creating Docker images for the intended K8s & docker-compose networking demos as part of the pipeline. It's all half-baked, sitting in the back of my mind currently. Will come back to this later.

One other interesting thing I should do is write up a Travis --> Github Actions doc like this one. Maybe this issue can even serve as a basis! Oh, the joy of migration.

On with it

I'm not really trying to invent the wheel here - while CI might need a proper refactoring down the road, for now it's quite enough to just mimic what we had in Travis but with Github Actions.

I'm following this guide and converting it to match the .travis.yml file in the repo. What we're going to do though is separate the single .travis.yml into two separate Actions - one for PRs and one for master builds. This will (probably) absolve us of the before_script.sh.

PR Action

Looking at an old build shows Ubuntu Xenial (also see here for an overview of the linux versions used by Travis agents) and the following Java & Maven versions:

 java -Xmx32m -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~16.04-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
$ javac -J-Xmx32m -version
javac 1.8.0_252
$ mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)

First things first - making sure that this action runs on pull requests that target master (we'll deal with actual builds of master later in a separate action):

on:
  pull_request:
    branches: [ master ]

Then converting the JDK and the Ubuntu versions:

on:
  pull_request:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-xenial
    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8.0_252

Then adding the new maven step:

on:
  pull_request:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-16.04
    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Build, test and generate docs with Maven
      run: mvn test -Ptest-output

That should about do it - confirmed working and committed here.

master Commit Action

Will do tomorrow / over the weekend. One thing to note here is that GitHub actions should have ways to absolve us of the shell hacks of make_credentials.py and after_success.sh, but I'd have to dig a bit deeper to be sure.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions