These workflows describe how a developer would work with Yodels build and CI system.
To create a new feature:
- update your local copy of the
develop
branch - create a new branch ('feature/my_feature')
- 'feature/' for features
- 'fix/' for bugfixes*
- 'locale/' for locale additions / changes
- when you are done, create a pull request into
develop
- once CI passed and reviews are done, you merge into develop (and are done)
* sometimes, a bugfix is implemented alongside a new feature. this is ok. you do not have to create an additional branch just to fix a bug. instead, just include it with your feature.
To publish a new release, you first have to merge develop
into main
:
- commit any last- minute changes now (into
develop
)- bump the app version
- ensure the app is ready to ship
- run unit and instrumentation tests on your local machine (full CI is expensive)
- on Github, create a new pull request that merges
develop
intomain
- once CI passed and reviews are done, you merge into main
Now, you have to create the release:
- on Github, draft a new release
- use the app version (versionName in build.gradle) as tag
- use
main
as the target - do not fill out the title & body (auto- build overwrites them)
- wait for auto- build to finish
- now you can fil out the title & body
- keep the body generated by auto- build intact
- do not rename the attached apk files
Yodel is automatically built using Github Actions with the following workflows:
the short CI runs on every pull request that is to be merged into develop
.
it only runs unit tests using the testDebugUnitTest
task. test results are published on the PR using EnricoMi/publish-unit-test-result-action
- Runs on all PRs into
develop
- Unit Tests Only
the full CI runs only on pull requests that are to be merged into main
(new releases).
this is because it includes instrumentation tests, which (at the moment) can only be run on macOS runners. These, however, use up the run minute quota 10x faster.
This makes instrumentation tests quite expensive. on the free tier, you could run the full CI only 10 (-ish) times a month.
- Runs on all PRs into
main
- Unit + Instrumentation Tests
- Very expensive to run
this workflow automatically builds yodel into four apk files (for each ABI) and creates a release on github for them.
it also includes unit tests (like the short CI), but does not publish them in any visual way (instead, a artifact of the xml files is uploaded).
at the end of this workflow, the artifact containing the built apk files is deleted.
This is to limit the impact on the storage quota (all four apks total almost 120Mb, or about 1/4 of the total quota)
- Runs when a new tag / release is pushed / created
- Overwrites existing release body
- Unit Tests + App Build
- Calculates and publishes checksums for the APK files