Create a single job called build (you can have as many as you want within a single Action) which runs on an Ubuntu container.

Instruct Github to execute this Action on any push to the master branch, or pull requests targeting master.

In the above action we perform the following steps: Thankfully the YAML markup is pretty readable. Name : Build on : push : branches : pull_request : branches : jobs : build : runs-on : ubuntu-latest steps : - uses : actions/ - name : Set up JDK 11 uses : actions/ with : java-version : 11 - name : Grant execute permission for gradlew run : chmod +x gradlew - name : Build with Gradle run. The below configuration is all we need to build our repo: This example will use Gradle, but Maven will also work just as well. In our case, we want to build and test our Kotlin or Java project. yml files which describes the workflow and steps to execute. These take the form of open source packages hosted within other repositories, but you can of course create your own custom actions taking the best bits from each.Īctions take the form of simple. By default, Github will suggest some common workflows relevant to your project (e.g if it’s a Node project run npm run build and npm test). Once you click on the tab you will be able to create your first Action. Your repository should have a new tab called Actions which is your new portal for anything CI related. You can think of it as pretty much the same as other CI tools out there, but you get the added benefit of full integration with Github, so now everything can be in the same place! Creating a a Gradle Build Action Now however, there is an alternative that’s built into Github itself - Github Actions. Previously, the most widespread tool for this is is probably TravisCI (which is free for open source usage).

run static code analysis tools or linters.

in general your main branch contains a fully working version of your project.

ensure that your project builds and runs on a wide variety of devices e.g different JDK versions/OS’ - or really that it can build on a machine that isn’t your local box.

automatically run deployment steps e.g to Heroku, AWS or Github Pages.

running a complete build on every change pushed to master (or any other branch) - including integration tests etc.running a small build on every pull request before merging.

Commonly this takes the form of something like: If you have a Kotlin/Java project of any reasonable size, you probably want some kind of CI (Continuous Integration) process running alongside the main development workflow.

Windows 7 operating system