If you ever wanted to pass in arguments to Gradle, I wrote a short post about your options!

https://www.liutikas.net/2025/03/24/Options-For-Options.html

#gradle

Options for Options - Ways to Pass Arguments to Gradle

When setting up your build, you might need to pass arguments to the Gradle, such as binary toggles like "release-build=true" or strings values like "my-key=m...

@Aurimas I have settled on env variables or files, mostly files actually unless they're a secret in CI and I'm too lazy to encrypt.
Property precedence always get me confused.
Task options feel like an anti-pattern. There are better options for CLIs than Gradle.
@mb Could you expand on the point about task options being an anti-pattern and there being better options for CLIs?

@tudortimi task options work but most of the time, if this is interactive, it shouldn't need to check the whole build state.
For an example, Gradle has `./gradlew wrapper --gradle-distribution-url ...`. This is getting me confused everytime because if I just want to update my wrapper, I now need to configure my full 100+ modules build and make sure it is in a good state.

I wish the Gradle cli would do this without it being part of my build.

@tudortimi this is just an example but most of the times, I found that distributing a CLI outside the build allow for faster iteration/cleaner UI.
@mb I think I get what you mean with the wrapper task. My experience has been to use options for testing related tasks, where it actually does need to run most of the build to be able to run tests.
@tudortimi right, I use --tests extensively as well.
For my own tests, I just use ENV variables. I could use optional command line parameters I guess. It just doesn't "feel" right because there is no bash completion and the error messages are a bit weird 🤷. So it's more or less equivalent to an env variable...