Add GitHub Continuous Integration #315
Conversation
|
If you're curious, most of my ideas for that workflow came from this article: https://medium.com/upday-devs/how-to-setup-github-actions-for-android-projects-a94e8e3b0539 |
|
Hey, that's really impressive work here. Thanks very much! I don't see any cryptominers, and the only nitpick is that one of the rules is called Feel free to rebase both PRs onto current master, otherwise I'd do so in the next days after completing review. |
penguin359
force-pushed
the
github-ci
branch
2 times, most recently
from
03b59cf to
80ad712
Compare
|
OK, this is now rebased onto the latest master with spelling error fixed. I guess I need to turn spell check on more often when editing in Vim. |
|
Once this branch is merged in, you should see pass/fail results embedded into the PR from the GitHub workflow. In the mean time, here are the results from this PR: https://github.com/penguin359/aprsdroid/actions/runs/1659439422 |
|
Any further changes you'd like for this PR before merging it? Don't worry, any crypto miners would be on the manual-di branch where it's easier to hide them. |
|
I've added support for saving logcat from all failed test runs on GitHub CI as a downloadable artifact and enabled the SD card so that functionality using it can be tested. Also, I fixed the badge in the README to just point at pushes to the master branch as the default URL will just so the build status of whatever the latest pushed branch or pull request is giving it little meaning. I was hoping there was a way to have it fill in the name of the current branch being viewed, but that seems to be a long-requested feature that is just too difficult for them to implement. The best recommendations are just to hard-code one or more branches of interest in the README similar to what was suggested here for Travis-CI: |
Currently, there are linting errors so the lint step is not marked as fatal.
This allows common parts of the CI to run only once and for the final testing to all be done in parallel.
Use a separate cache for SD-enabled versions of emulator
penguin359
force-pushed
the
github-ci
branch
4 times, most recently
from
6ec7a06 to
a723873
Compare
The latest SDK Commandline tools starting with release 9.0 require Java 17 to execute. These are used by the Android Emulator GitHub Action so it will fail to run if the default Java environment is older than 17. Need JRE 17 to be installed and default, but not the full JDK. However, the build toolchain for Scala still requires to be run under Java 11 so we need both installed. We just need to make sure JAVA_HOME is set appropriately for JDK 11 when calling Gradle. Set JAVA_HOME to JDK 11 for gradle on instrumented tests.
Hardware acceleration is now possible with Linux runners on GitHub and have much better performance so no need for macOS anymore.
|
I've updated this branch to the tip of master and fixed some issues that have cropped up on it. It is currently passing all tests in under 8 minutes and should be ready to merge. It will automatically attempt a build and provide feedback on any PRs requested to be merged into the master branch. Here's a recent, successful run: https://github.com/penguin359/aprsdroid/actions/runs/10264232632 It seems that the SDK Commandline tools are now compiled with Java 17 as the target so I had to add a step install JRE 17 in addition to JDK 11 and then make sure JAVA_HOME is explcitly set correctly before calling |
With Travis CI no longer free for OSS, adding a Github workflow action for running a full CI against new commits. This will build, test, and upload debug artifacts for APRSdroid on success. This will build and test APRSdroid on API levels 15, 21, 24, and 31 using both AOSP and Google API system images. It is broken up into three jobs: compilation, unit tests, and a 4x2 job matrix for instrumented tests on the various platforms. After tests have completed, it will upload the test reports and a debug APK as artifacts. You can see the results for one test run here:
https://github.com/penguin359/aprsdroid/actions/runs/1648420289
I have to say, GitHub workflows are much easier to work with for Android than Travis CI was. I probably went a little overboard with this one.
At the moment, this is mostly a compilation test as there are very few tests written so far, but it should be helpful as more testing can be added. There are a lot of knobs in this so feel free to tweak the settings I have chosen. I picked the oldest API I could to test the minimum API level allowed as well as the newest one out there. I was unable to use API 14 as there are no Intel images for that version.
I have the current workflow file configured to only upload test reports for a job when there's a failure, but it can be changed to always if preferred. The Debug APK is only uploaded upon a successful test run on Google APIs level 31.
I set it up so that it only does the build of all code and unit tests once, but will use those outputs for each of the instrumented test jobs. As it fires every job up in a new VM, the checkout and JDK install need to be done each time, but I think it's still an improvement. It also runs the linter, but it's marked to not fail the test as there are currently lint errors in the project. I also set up caching for the emulator images so it can just launch it from a saved snapshot instead of a full boot every time. This is configured to run for every pull request or push to any branch and provide a report.
To make this a fully-working build, I have it configured to set an API key through a Repository secret configured for mapsApiKey. I have mine set to a development key I acquired for this project. You might one to add one to the Settings->Secrets->Repository Secrets to one that's good for development if/when we get to testing that part of the app.