Open penguin359 opened 2 years ago
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 intrumentation:
without an "s".
Feel free to rebase both PRs onto current master, otherwise I'd do so in the next days after completing review.
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:
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 ./gradlew
. This seems to work well and allows us to use the latest GitHub Actions available while still working with the Scala build system. Also, switched to the Linux runner images which are faster and have more resources available now that the Android Emulator can be used with hardware acceleration under them.
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.