I need a git hash in the name of the final apk. U...
# gradle
u
I need a git hash in the name of the final apk. Using the usual snippets on the internet gives me warning about it being ran in the configuration phase How do I delay this to execution phase? Is it even possible?
e
no. if you need the file to have a different name, rename it when copying elsewhere.
u
I only do this for release which is only ran on CI - is it worth the hassle?
(I also question if this is necessary at all - since as I said, its only on CI and 99% nobody looks at the binary manually) is it such big infraction in your eyes?
d
You can use the
onVariants
part of the DSL to define a copy task and relocate it. At the same time, does your build actually know/care about the SHA? If your set up is anything like the one I deal with, the actual SHA of the check out isn’t going to be known to the pipeline, just the branch (e.g.,
release
) and not the actual SHA. If that’s the case, then to get the SHA would require a command line statement to get it (such as
git rev-parse --short HEAD
or
--long
). In that case, would a post build phase in the CI make more sense to have a script that collects and renames the APK for this need? It’s been my experience with larger teams that when you start baking items like this into your build scripts itself rather than clearly defined phases in your CI, the larger group easily looses sight of these sorts of items.
u
yea yourr right, nobody really cares about thr hash since scripts upload it to play store, not humans (it's just for the feeling of safety if I need to examine stuff manually) its mostly from time when there was no CI, and gradle wasn't yet resolving config lazily or whatever is the term
maybe inserting the git hash into a BuildConfig somehow and displaying it inside the app would be more beneficial?
Copy code
android {
    defaultConfig {
        buildConfigField "String", "GIT_HASH", "..."
    }
}
that however would be the same thing right? here it needs to be eagerly ready, or can I mutate the buildConfigFields postprocess-y? so we're back to square one again - same issue