Display useful build info for dev builds, both inside the app and in Firebase App Distribution

[duckth]

I have started working on the Android-part of this problem on the branch feature/duckth/add-debug-build A debug version has been added to the gradle build, along with a new Firebase app for this debug version. Since there are now multiple Firebase apps, we need to add the name when initializing - I have added flutter_dotenv for this. This will then also require a .env file to be added to the production pipeline

Not sure where to begin with iOS though!

[jonasanker]

@duckth While I only have lightly skimmed the documentation using the Flutter feature Flavours could maybe solve what we're trying to achieve here.

See relevant documentation

• flavors for Flutter
• Flutter Flavorizr package

[duckth]

@jonasanker I initially used flavours to set it up but deemed it overkill as the build type seemed to get the job done, but the flavorizr package does seem pretty clean. Though, it requires Ruby for some reason so this might complicate things - maybe we could run it in a container?

[jonasanker]

Yea, it requires Ruby on iOS specifically. We are able to add Ruby (if not already existing) to the GitHub mac build agent if needed. On Android, it should work out of the box according to documentation.

[marfavi]

AFAIK there’s no way to do this on iOS. Right now we have the -prod suffix on Android builds for production. (I think -dev suffix for other builds as well; need to confirm!)

[marfavi]

This is how I see the issue currently:

For a long time, app builds off the develop branch has had the version number 2.1.2.

1. Someone merges a PR into develop.
2. GitHub Actions workflow builds the app and uploads it to Firebase App Distribution.
3. I get an email notifying me of a new app version 2.1.2 (+build number) is ready for testing.

Ideally, I would get an email notifying me of a new app version <latest app release version>-develop (plus the build number) is ready for testing. For instance, if the latest app release version is v3.4, the uploaded develop build should have version number 3.4-develop.

[jonasanker]

The challenge here is that we only apply a tag for production releases on the production branch. This tag is not visible for the develop branch and thus the develop branch keeps having the 2.1.2 as the version.

We might be able to solve this by either merging production to develop (should be investigated) or querying for it through the GitHub API.

Maybe we should reflect on what is useful to have as a developer. When you want to test the app, what information do you need to be able to correlate to the commit? Would that be the pipeline execution Id which built the app, is it the commit of the app or others?

I am wondering that maybe having a bump of the latest production release is not the right problem we are solving.. To give an example if you have X build after 3.4-build, what does that tell? It doesn't make you able to point to which develop build the app is. You just know that it is a later build than what was in production. But maybe that is also alright. I'm just thinking out loud 😊

[marfavi]

Include commit hash in the version name?

For instance, for the app built on branch develop and latest commit being bddf0ca would have the following app version/name:

# any of the following formats:
3.4-develop [bddf0ca]
3.4-develop-bddf0ca
3.4 (branch develop, commit bddf0ca)
3.4 (develop:bddf0ca)

# ...alternatively
3.4-beta (develop:bddf0ca)

---

This could be further expanded for other branches as well. Let's say I have a pull request that wants to merge branch migrate/dart3 into develop. If we wanted to build/distribute a test app for pull requests at some point, the version number of the app built on the branch migrate/dart3 would be named:

3.4-migrate/dart3 [bfb0b1b]

# ...alternatively
3.4-alpha (migrate/dart3:bfb0b1b)

[jonasanker]

I like the idea of having the option to create a test release from feature branches too.

Maybe the version is not really necessary in development at all? A feature branch can quickly become several versions behind and then the version name would be misleading.

On top of my head, I would suggest this naming pattern like this

develop-[pipeline run number]
features-[branchName]-[pipeline run number]

[marfavi]

still required for useful iOS version naming

[marfavi]

Related issue #537 was addressed by #546, but we still need to fine tune the message and ensure that the info is retrievable from within the app itself. The issue name has been updated to reflect this