Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Document how to test on release builds #17952

Closed
BrayanDSO opened this issue Feb 9, 2025 · 7 comments · Fixed by #17961
Closed

docs: Document how to test on release builds #17952

BrayanDSO opened this issue Feb 9, 2025 · 7 comments · Fixed by #17961
Labels
Docs Documentation changes Good First Issue!
Milestone

Comments

@BrayanDSO
Copy link
Member

The task is to document in the Wiki how to test the app in release builds. Try running the tests yourself first, then document it. If you develop any kind of script or add any tips, it would be tremendous.


Mike's description in Discord should help:

  1. you'll need to generate the build as release, which requires a keystore configured for signing - you'll need to set one up and remember 1) the location of it, 2) the key alias 3) the store password and 4) the key password

That's a little annoying to set up but it's simply the price of entry for doing app signing

  1. release build for androidTest is all turned on / managed by environment variables - set them as we set them in the emulator workflow, but using your values from 1 above

TEST_RELEASE_BUILD: true
# could be better, '/home/runner' should be '~/' but neither that nor '$HOME' worked
STOREFILEDIR: /home/runner/src
STOREFILE: android-keystore
STOREPASS: testpass
KEYPASS: testpass
KEYALIAS: nrkeystorealias

What I do is I have a keystore setup, and I have a little script right next to it that exports all those vars
I should say it's not "easy", because there is some setup, but once you've got the keystore done and a little script that sets the env vars to match the keystore, then it's easy to iterate / do it whenever
That is is testable is kind of amazing, I don't even want to go into the details other than to say that it is kind of a crazy hack, and voczi deserves a lot of the credits, respect for that.

And that it is testable is the only way I was going to turn it on, fearing we'd have problems like what you're looking into in the future - there are always problems. But we can test them and fix them at least. Which unlocks like a 30MB app savings, so...on balance worth it

@BrayanDSO BrayanDSO added Good First Issue! Docs Documentation changes labels Feb 9, 2025
@Sahil06012002
Copy link
Contributor

picking up this one.

@tarun1sisodia
Copy link

Okay currently working on documenting how to test the app in release builds. I will include keystore setup, environment variable configuration, and troubleshooting tips. Let me know if there are any specific points you'd like me to cover!

@tarun1sisodia
Copy link

yeah , okay go for it , no problem

@Sahil06012002
Copy link
Contributor

Thanks @tarun1sisodia

@mikehardy
Copy link
Member

It may be that the best way for everyone to have the ability to test release builds is to include a "fallback-release-keystore.jks" file in perhaps the tools/ subdirectory, and have the release signing config fall back to that if no variables are provided in the environment

The creation of a keystore and configuration of a environment variables is the part of the process that is really annoying, in my opinion.

Doing that would remove the need for 90% of the documentation stuff I wrote to Brayan

@Sahil06012002
Copy link
Contributor

Sure @mikehardy ,I'll be adding an fallback-release-keystore.jks file as a fallback when building a release variant.

@Sahil06012002
Copy link
Contributor

@mikehardy, added the suggested changes in this pr : #17961

@github-actions github-actions bot added this to the 2.21 release milestone Feb 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment