Running CI via GitHub actions

[stigi]

Change description

This PR reenables CI for the Android SDK. The previous CI setup was configured for CircleCI and wasn't running. Now things run again via GitHub Actions.

Workflows

Gradle Build and Tests

Builds and tests the SDKs and example app.

Doing a ./gradlew build also runs the linter, which currently fails, so I've added -x lint to exclude the linter. I will address the linter error in a seperate PR (#23).

linter error

  /Users/ullrich/Projects/magicbell/magicbell-android/sdk/build.gradle:15: Error: Google Play requires that apps target API level 33 or higher. [ExpiredTargetSdkVersion]
      targetSdk 31
      ~~~~~~~~~~~~

     Explanation for issues of type "ExpiredTargetSdkVersion":
     Configuring your app to target a recent API level ensures that users
     benefit from significant security and performance improvements, while still
     allowing your app to run on older Android versions (down to the
     minSdkVersion).

     To update your targetSdkVersion, follow the steps from "Meeting Google Play
     requirements for target API level",
     https://developer.android.com/distribute/best-practices/develop/target-sdk.
     html

     https://support.google.com/googleplay/android-developer/answer/113469#targetsdk
     https://developer.android.com/distribute/best-practices/develop/target-sdk.html

Instead of running only debug tests I opted for running all tests via ./gradlew test which runs testDebug and testRelease tasks in all targets (mostly sdk but also sdk-compose and example app if we add tests there).

The setup-gradle action will also manage build results cache, but only write to the cache from the default (main) branch.

The google-services.json file, which is needed to build the example app, is stored base64 encoded in the Github action secrets.

Gradle Dependency Submission

The PR also adds the dependency-submission action from the official gradle actions pack to support vulnerability tracking in our SDK via dependabot.

Fixing tests

The biggest challenge in this PR was debugging why tests were failing on CI, while they consistently passed when run locally. It turned out that the test assertions via coVerify(...) were flaky. They are used to verify how often a stub method was invoked from a kotlin co routine (aka, asynchronous). On my fast machine those asynchronous tasks weren't a problem. On the (presumably) slower CI machines the coVerify calls needed an optional timeout. I gave all a 1 second timeout which fixed the flakiness and let tests pass locally and on CI.

Test Plan

Test run, fail (I saw them fail a lot!) and test failures are reported in Checks and annotated to the PR.

Type of Change

• Bug fix
• Feature
• Enhancement

Guidelines

• A changeset is included, or the change is not noteworthy enough to warrant one