Hm, that is not a bad idea. It could work for my case. I was however thinking further on this and I don't really like my PR in the first place. After submitting it I started thinking that it would be much better if we had just gradlew_params and the default value could be

--build-cache --max-workers 2 --continue assembleRelease ...

What we have right now. And then we could override it with whatever we want. I know this is again a breaking change, but it allows better flexibility with less params. What do you think?

The commands in this Orb are meant to cover the basic use cases, with some customisation options so it's flexible enough to use with most apps. The idea isn't to be infinitly flexible.

If a command doesn't offer the flexibility that someone needs, they can always just write a custom step and ignore the library one.

@matt-oakes that's a fair point and I think that by changing the above it will work with "most apps" as you said. I know that I can copy it and modify it, but I still think that if we could provide something that works for "most apps" it will improve developer productivity. It's much better to configure a line, than to copy 50 just because one can't configure a line...

I think that gradlew_params would be the most versatile approach and will cover most use cases.

It's up to you. If you don't want this, I'll close the PR.

@matt-oakes I just realized that this PR status is "change requested". So what do you want me to do?
add flavor or default gradlew_params or nothing at all :)

I personally am in favor of gradlew_params. But I feel that flavor is not making it better. Tomorrow someone will need yet another param and when do we say enough is enough? On the other hand gradlew_params let's users do their thing...

I see what you mean about making it so people aren't required to break out from the command.

Could we do both for the best flexibility?

If you added in the flavour with the default being empty, then we can make this a none breaking change.

You could then also include a gradlew_params parameter if people want to customise it further.

Would that work or is that just complicating things even more?

You mean like <<parameters.additional_gradlew_params>>:

"cd <<parameters.project_path>> && chmod +x gradlew && ./gradlew --build-cache --max-workers 2 --continue assemble<<parameters.flavour>><<parameters.build_type>> assemble<<parameters.flavour>>AndroidTest -DtestBuildType=<<parameters.build_type>> --stacktrace <<parameters.additional_gradlew_params>>"

or if gradlew_params set - ignore all other params and just use gradlew_params?

I think additional makes more sense. If they want to override the whole thing then they may as well just not use the command and write their own.

@matt-oakes just started implementing this and realized that it won't work the way you are suggesting.
The command we have to execute is:

./gradlew assembleDevelopRelease assembleDevelopReleaseAndroidTest -DtestBuildType=release 

just adding a flavor variable won't cut it. The command right now is:

command: "cd <<parameters.project_path>> && chmod +x gradlew && ./gradlew --build-cache --max-workers 2 --continue assemble<<parameters.build_type>> assembleAndroidTest -DtestBuildType=<<parameters.build_type>> --stacktrace"

if I add flavor=Develop then I would end with assembleDevelopRlease which is fine. But the AndroidTest would be assembleDevelopAndroidTest - which won't work...

I'm giving up on this. I'll copy the whole android_build job in our project and just modify the build step there.

@matt-oakes is it necessary to run Gradle task assembleAndroidTest?

I would like to help and fix this issue as we use product flavors