mozilla-mobile/perf-frontend-issues

Figure out how to make signing release builds easier for developers

mcomella opened this issue · 3 comments

mcomella commented

Post GA?

Why/User Benefit/User Problem

In order to use "release" build variants like forPerformanceTest, we have to do our own signing. However, it's non-trivial integrate release signing into the regular Android Studio build process: this bug is to make it easy.

Impact

Without this, setting up local performance builds is an annoyance: developers have to do something hacky like adding local signing configurations and remember not to check them into the tree.

Acceptance Criteria (how do I know when I’m done?)

  • It is easy for developers to create signed forPerformanceTest builds
  • Documentation (e.g. in README) is updated
  • Folks are notified of any changes to their workflow

Solution ideas:

  • We check a debug.keystore into the tree that signs forPerformanceTest builds and provide a signing config for it
  • Developers can specify a path to their debug.keystore and it will integrate the signing
  • Developers add custom run configs with signing in AS
mcomella commented

Can we just land the signingConfigs.debug line, as suggested in the wiki, in-tree? This would sign all forPerformanceTest builds with the debug keystore. This seems fine to me since we're not releasing the builds. We might have to update the TC configs though such that it no longer tries to sign forPerformanceTest builds with a release configuration.

@hawkinsw What do you think?

hawkinsw commented

Can we just land the signingConfigs.debug line, as suggested in the wiki, in-tree? This would sign all forPerformanceTest builds with the debug keystore. This seems fine to me since we're not releasing the builds. We might have to update the TC configs though such that it no longer tries to sign forPerformanceTest builds with a release configuration.

@hawkinsw What do you think?

Yes! I agree! That is, of course, with the caveat that I see no documentation anywhere about the validity of the signingConfigs object. That's not our problem -- just the sad state of the gradle Android build documentation, as far as I can tell. :-)