Change default buildType/flavor to release

[divyanshupundir]

Most people who will use this action will need it for release builds to track their app delivery statistics. Debug or staging build sizes may vary vastly on library addition as minification is not generally applied.

[zsfVishnu]

Yup, you're right . I've already created an issue for this : https://github.com/zsfVishnu/apk-size-tracker/issues/3 . The only extra input we would then need for this is the signing keys, which we can either store in the git secrets or as a config file somewhere.

[divyanshupundir]

Interesting, I didn't think about the signing keys. If you can add a method to configure the build.gradle of the app and set the debug build configuration (like minification) to the same as the release build. Then you can quite easily track the apk size without requiring the signing keys.

[zsfVishnu]

@divyanshupundir that's actually a great idea. In fact if i remember correctly, we can pass property values via command line itself using the -P flag. Something like this gradlew assemble -P<property>=<value>.

• If we're able to add all such properties which can bring the debug build as close to the release build as possible, we'd be able to make the users use this action with no change in their code. In case some flags or properties can't be altered , we might have to make the user modify their code.

• Another thought i had is to generate a dummy signing key , which we can then use to sign these apk's. Since we don't persist any app or builds, it should be safe as well.

• In addition to the above ones, we could provide means for on-prem runs, for them to have the exact app metric of their releases. If the user can provide the keys via their hosted set up (say S3) and then provide their own github machines (runners), then they could have the best of both worlds without worrying about keys.

[divyanshupundir]

@zsfVishnu, on-prem integration sounds like a good idea. And what if you create something like a fastlane integration? In that case the app won't need building twice. The same build will be used in deployment and metric scan.

For the case in which debug build is configured is a similar manner as the release, you can have a buildtype.properties file with properties like:

debug.minify=false
release.minify=true
...

common.shrinkResources=false # For common config to the build types

The users just need to create and use this file. All you need to do now is replace the debug values in the file with the corresponding release values as one of the first steps of the GitHub action.