Allow getting the release key signing passwords from environment variabl...

[AdamClements]

Useful for CI builds where you don't want to put the passwords in source control but also don't want to interactively type the passwords in.

[alexander-yakushev]

Can't you put passwords into profiles.clj? I haven't tried, but I think that should work too.

OK, for CI builds profiles.clj is probably harder to customize. Then the change makes sense.

It will be great if you use this priority order (explicit over implicit):

storepass
(System/getenv "STOREPASS")
(when dev-build "android")

[AdamClements]

You could, but it would be insecure and wouldn't work for most continuous integration setups. I'm using Travis (which I would totally recommend for building and releasing lein-droid by the way, I might submit a separate pull request setting up continuous integration and building for you) and it has a nice neat way of including encrypted environment variables in your build file which get decrypted only when doing a build on the main repository. This is also the way I've seen it done on various other ci systems for ant android projects. On 20 Jun 2014 07:48, "Alexander Yakushev" notifications@github.com wrote:

Can't you put passwords into profiles.clj? I haven't tried, but I think that should work too.

— Reply to this email directly or view it on GitHub https://github.com/clojure-android/lein-droid/pull/96#issuecomment-46649499 .

[alexander-yakushev]

OK, I see. What about reordering password sources?

[AdamClements]

Oh, sorry, I was responding directly to the email and it didn't include anything beyond the first line of your message. You're right actually, the order isn't quite right, but I don't think I like yours either - you have the potential to accidentally sign a debug apk with your release key, I think the best arrangement would be

(when dev-build "android")
(System/getenv "STOREPASS")
storepass

[alexander-yakushev]

In your example it is impossible to use a debug key with password other than android, and this is quite odd limitation. And I don't see why you should keep your release keys in your environment when you do debug builds.

[AdamClements]

Who would want to use a debug key with a password other than android? Nobody. It's a debug key, you should be using the autogenerated one with the autogenerated password, if you use anything else then you've misunderstood the process and are doing it wrong.

And you shouldn't keep your release keys in your environments when you do debug builds, but you might accidentally forget to clear them when you've just done a debug build, and in that situation, you don't want to start lein-droid to start signing your debug build with your release keys!

[AdamClements]

In fact the more I think about it (accidentally leaving environment variables floating about, or having them floating about from other processes), the more I think I was actually right the first time, the order should be dev build -> android, if you have it set in your project map (or by extension your profiles.clj), that's final, if you don't then it looks in your environment. That gives least surprise in all the cases I can think of.

[alexander-yakushev]

Let's settle with:

storepass
(when dev-build "android")
(System/getenv "STOREPASS")

If user wants to explicitly set a password for keystore, he should be able to do it regardless of the build type.

[AdamClements]

If they set it in their profiles.clj, that will stomp over everything, release and debug. Given that these only really come into play in release mode, I wouldn't be surprised if the users expected them to be ignored elsewhere and would be surprised that setting it in their profile breaks things...

I very strongly recommend the dev build one coming first and being absolute. This is what the android build tools do too, it even says in the signing docs that if you give a custom debug keystore, the passwords should still be the same: http://developer.android.com/tools/publishing/app-signing.html#debugmode

[alexander-yakushev]

If Android tools suggest that as well, it's completely different story. Thank you!