Description of the feature request
Support wildcard matching when specifying a deploy apk using the hockey app plugin
Use case / for what or how I would use it
Flexibly deploy a customised apk file name without having to know the details in the hockey app plugin. i.e. if my build generates an apk with file format “myapp-${version}-${buildType}” I could specify something like this in the hockey app plugin
bitrise/deploy/myapp-*-release.apk
The main use case here is that the apk name is dynamically generated based on bitrise build number
Hi @mobile-dev-dius,
Thanks for the details!
Just a quick question, as I believe this should already be possible - how do you generate that APK? With which step?
In general if you want to deploy a single APK with dynamic name the suggested method is to save its path to a fix environment variable (e.g APK_PATH) and then set that env var ($APK_PATH) as the apk path input of the deploy step (Hockey App in this case).
In most cases if you use our standard/default steps this should be handled automatically, e.g. the Gradle Runner step scans for .apk files in the src dir automatically and exposes the path in the BITRISE_APK_PATH env var, which is set as the apk path in the HockeyApp deploy step by default.
Hi,
Thanks for the reply. I’m just using standard gradle config to generate the apk file. What I end up with is three apks. A debug and release apk (with my custom name) and one more, which is just the default app-release.apk. I’m not sure how the third is being generated.
The apk is generated in the gradle runner step.
BITRISE_APK_PATH_LIST contains all three apks, BITRISE_APK_PATH contains the default app-release.apk which is not the one I want.
Please use the Gradle Runner step’s APK file include filter input (export config category) to specify a more precise APK filter. E.g. if you want to select myApp.apk to be the one BITRISE_APK_PATH points to you can have a filter like */myApp.apk (the leading * is important, as this is a path filter) or *myApp.apk instead of the default *.apk.
1 Like
Thanks, will give it a go. I think I tried without the leading wildcard!
Glad to hear! 
Should I close this #feature-request? 
