search

olmps / memo

Memo is an open-source, programming-oriented spaced repetition software (SRS) written in Flutter.
BSD 3-Clause "New" or "Revised" License
1.83k stars 159 forks source link

Release Configuration + Fastlane + CI #62

Closed ggirotto closed 3 years ago

ggirotto commented 3 years ago

@matuella

will bump AND COMMIT to this repository when a new release is successful?

It wasn't. Fixed on my last commits.

will it reset AND COMMIT to this repository if a new version (major, minor or patch) is updated?

The build number is controlled by Fastlane lanes, but the version bump is our responsibility. It will not update the version automatically, just bump the build number

what happens if one of the builds fail (because we know it's impossible to guarantee atomicity in these two operations)? What is our fallback here? Could it retry?

If any phase of the scripts fails, it doesn't execute the next phases. It means that, it may successfully update the iOS app but fail in the Android lane, as an example. We don't have a fallback in the script itself. If it failed because an error in the workflow itself, we need to fix it and then submit a new PR pointing to main with the fix, and it will naturally trigger the release workflow and repeat the process. If it failed due to an external source, like a connection issue with the stores, we just need to re-run the workflow through Actions tab, since the workflow script itself doesn't have any kind of retry workaround or stuff like that.

I think you could go address these particularities in the ARCHITECTURE document as well.

I added a few docs on ARCHITECTURE.md pointing to the release lanes and Fastlane files. I didn't write much about how the release workflow and the Fastlane files work because all of the mare well documented and are kind of self-explanatory, so I kept the explanation in the ARCHITECTURE.md simpler.

Also, I'm not 100% sure, but I can't remember if we can't use the flutter's build number because of a limitation in fastlane or in the flutter ecosystem itself. Here I am assuming that we DO want the same build version for both iOS and Android, and that we can reset the build number for the Android's ecosystem.

Yes, we are not using Flutter's build number defined in pubspec.yaml, we are using those specified in the platforms settings (build.gradle for Android and PBX for iOS). We use pubspec.yaml to retrieve the version code only (major.minor.patch), but the build number are specified and managed directly in the platform source files.

iOS Fastlane has an additional feature that it sets as the build number the latest build number available on testflight + 1. Android just bumps the build number that exists in the local build.gradle, even if this build number is not in Google Play store yet. This because iOS has an action that supports fetching this information from App Store Connect, while Android doesn't.

we can reset the build number for the Android's ecosystem

We cannot reset the build number for Android apps, only in iOS. It means that the Android build number will increment indefinitely, while iOS will reset on every version change.

ggirotto commented 3 years ago

@matuella Agreed. Please read the new docs on ARCHITECTURE.md and let me know what you thought about it. If you missed some information, please let me know because I'm biased since the script was written by me, so everything looks obvious in my point of view