Skip to content

Latest commit

 

History

History
83 lines (55 loc) · 3.54 KB

BUILDING.md

File metadata and controls

83 lines (55 loc) · 3.54 KB

Development Workflow

These workflows describe how a developer would work with Yodels build and CI system.

for new Features

To create a new feature:

  1. update your local copy of the develop branch
  2. create a new branch ('feature/my_feature')
    • 'feature/' for features
    • 'fix/' for bugfixes*
    • 'locale/' for locale additions / changes
  3. when you are done, create a pull request into develop
  4. 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.

for creating a new Release

To publish a new release, you first have to merge develop into main:

  1. 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)
  2. on Github, create a new pull request that merges develop into main
  3. once CI passed and reviews are done, you merge into main

Now, you have to create the release:

  1. 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)
  2. wait for auto- build to finish
  3. now you can fil out the title & body
    • keep the body generated by auto- build intact
    • do not rename the attached apk files

Github Workflows

Yodel is automatically built using Github Actions with the following workflows:

Short CI

workflow file

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

Full CI

workflow file

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

Auto- Build

workflow file

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