feat(android): Bundle GITHUB_SHA into Android client

[jamilbk]

Closes #6400

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
firezone	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 26, 2024 9:29pm

[thomaseizinger]

git-describe is made for this but it is output is much nicer if you have a tag it can use.

[thomaseizinger]

What about builds that don't happen on CI? Where are the builds made that get submitted to the play store for review?

[jamilbk]

It'll be unknown. Playstore builds always happen via the Kotlin workflow in CI.

[jamilbk]

git-describe is made for this but it is output is much nicer if you have a tag it can use.

Yeah I think I would be open to tagging these if there was automation, otherwise we'll inevitable run into cases where the tag doesn't match the published release. It seems like it could be possible using the Publishing API and some automation: https://developers.google.com/android-publisher/api-ref/rest

[thomaseizinger]

git-describe is made for this but it is output is much nicer if you have a tag it can use.

Yeah I think I would be open to tagging these if there was automation, otherwise we'll inevitable run into cases where the tag doesn't match the published release. It seems like it could be possible using the Publishing API and some automation: https://developers.google.com/android-publisher/api-ref/rest

I found this: https://github.com/marketplace/actions/upload-android-release-to-play-store

It is also referenced in a couple of blog posts on automating Android releases.

How about this:

• Make draft releases like we do for the other artifacts and attach the APKs to them
• Trigger the above workflow when a release gets published (https://docs.github.com/es/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#release)

[jamilbk]

git-describe is made for this but it is output is much nicer if you have a tag it can use.

Yeah I think I would be open to tagging these if there was automation, otherwise we'll inevitable run into cases where the tag doesn't match the published release. It seems like it could be possible using the Publishing API and some automation: https://developers.google.com/android-publisher/api-ref/rest

I found this: https://github.com/marketplace/actions/upload-android-release-to-play-store

It is also referenced in a couple of blog posts on automating Android releases.

How about this:

• Make draft releases like we do for the other artifacts and attach the APKs to them

• Trigger the above workflow when a release gets published (https://docs.github.com/es/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#release)

How does this solve the review rejection possibility though? It happens often enough that we should account for it.

We need it to happen the other way around. When the app is approved, publish its release and attach the APK.

[thomaseizinger]

How does this solve the review rejection possibility though? It happens often enough that we should account for it.

We need it to happen the other way around. When the app is approved, publish its release and attach the APK.

It doesn't directly. Could we just treat such version numbers as burnt and make a tag after? We can still merge the changelogs and stuff into the new one.

[jamilbk]

It doesn't directly. Could we just treat such version numbers as burnt and make a tag after? We can still merge the changelogs and stuff into the new one.

Hmm let's move discussion to #3321