Hockey App Deploy

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


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.


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!

Let us know how it goes! :wink:

Worked perfectly!


1 Like

Glad to hear! :slight_smile:

Should I close this #feature-request? :thinking:

Closing this #feature-request