Unless otherwise specified, these files all go in the root of your Github repository.
We use Travis CI to build and test on each commit or pull request to the Github repository.
The Travis setup is all the defaults, plus this as .travis.yml:
# Travis build script for mineman
# Use new container infrastructure to enable caching
sudo: false
# Use Maven
language: java
# Caching so the next build will be fast too.
cache:
directories:
- $HOME/.m2
# Only re-download spigot if we don't have spigot in the repo
before_install:
- if [ ! -d "$HOME/.m2/repository/org/spigotmc" ]; then ./installSpigot.sh 1.12 ; else echo "Not compiling Spigot because it is already in our maven" ; fi
# Set the final name using pom-fu
install:
- mvn install -DfinalName=release -DskipTests=true -Dmaven.javadoc.skip=true -B -V
# You fill out this section by encrypting the key using the travis utility
# Note that the api_key is safe to put here because it is actually encrypted
deploy:
provider: releases
api_key:
secure: <Your travis encrypted github release key here>
file: target/release.jar
skip_cleanup: true
# Modify this to build on every commit
on:
tags: true
As you can see from this script, we do the following:
- Use
javaas our language for Travis. This sets up the default Maven testing script. - Cache
$HOME/.m2, which is the Maven repository. This means that we won't need to rebuild Spigot every time we build the plugin. before_installing the plugin for testing, we download and build Spigot using the script (see attached file) if it isn't already in the cache.- When we
installthe plugin for testing, we set the finalName of the jar torelease, so we get the jar inttarget/realease.jar. See the section on thepom.xmlfor how this actually works. - After the tests pass, we upload the finished
release.jarto a Github release, iff this build has a Github tag.skip_cleanup: truestops Travis from "cleaning up" our built jar before uploading it.
To generate a deploy key, go to the Github UI page for doing that.
Check the box for public_repo because this key will need to upload the release.jar to the release.
Your key should have a descriptive name like "automatic releases for Username/Repo" for organizational purposes.
It's best practice to generate a new key for each repository you set up, so you can revoke them individually if needed.
Once you have your deploy key, you need to encrypt it with the Travis public key of your Github repo.
Easiest way to do this is to use this site, second easiest way is to use the travis command line tool, but that will eat the comments in your .travis.yml.
You put the encrypted deploy key into the spot marked in the travis snippet above.
You will need to add the following to your pom.xml:
<properties>
...
<finalName>${project.artifactId}-${project.version}</finalName>
...
</properties>
Later on:
<build>
...
<!-- Override the final name for travis if set -->
<finalName>${finalName}</finalName>
...
</build>
Together, these allow us to specify the finalName of the Maven jar, while defaulting to the normal finalName.
We use this in the install step of .travis.yml (see -DfinalName=release) to get a consistently named jar as output from Maven.
We use Jitpack to serve the built jars as a Maven repo.
Use this as your jitpack.yml, but be sure to change <REPO HERE> to the actual name of your Github repository.
# Download the version, assuming it is a tag
# Just fail if it doesn't download
before_install:
- echo $GROUP
- echo $ARTIFACT
- echo $VERSION
- echo "Downloading release jar for version $VERSION from `echo $GROUP | grep -oP '(?<=com\.github\.)\w+'`/<REPO HERE>"
- wget https://github.com/`echo $GROUP | grep -oP '(?<=com\.github\.)\w+'`/<REPO HERE>/releases/download/$VERSION/release.jar -O release.jar
install:
- mvn install:install-file -Dfile=release.jar -DartifactId=$ARTIFACT -DgroupId=$GROUP -Dversion=$VERSION -Dpackaging=jar
What this does is replace the normal Jitpack build proccess with a fetch to the Github release that we just published using Travis CI. First, we grab the compiled jar from the release. Then, we install that jar using the information Jitpack provides via environment variables.
NOTE: this assumes that the version you specified in your dependency for projects depending on this project is a legitimate tag/release in the Github repo.
If this is not the case, the jitpack "build" will fail because it can't find the release.jar.
You should add Jitpack as a Maven repo:
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
And add the project like this:
<dependency>
<groupId>com.github.CivClassic</groupId>
<artifactId>CivModCore</artifactId>
<version>1.6.9</version>
</dependency>
You can replace CivClassic with your actual Github username, CivModCore with your actual Github repo, and 1.6.9 with your actual package tag, as in the release (see note in Jitpack section).
If your project uses multiple Maven modules, it will work as intended, as per the Jitpack docs.