Power of Gradle command line arguments
Have you ever faced a situation when you needed to tweak your build process just a little for some specific case? The change that you need to do might look very small and easy, but you don’t know hot to make it work without changing the current build process. There might be a chance that you don’t know or just forgot about Gradle command line arguments, which can bring a solution for much-needed flexibility of your build script.
A couple of days ago our team accidentally released a version of the application, which we are working on, with missing string resources for some translations. Of course, we want to be sure that it won’t happen again and the only viable option is to automate it! But, at first, I need to give you some overview of our current release process to be sure that we are on the same page.
- We are running lint checks against every pull request and gathering stats from it in order to feed them to the Jenkins Android Lint Plugin. Based on these stats we have a certain threshold for a maximum amount of violations which are allowed for a build to be marked as successful. In order to be able to gather these statistics, we want to be sure that build will be finished without errors even if it contains some lint violations. For that purpose, we had to make this adjustment to our
Which is not ideal, of course, but we haven’t seen other option back there.
- We have a localisation management tool integrated into our CI system so we don’t have to care about translations during the development process. For that reason our
So we won’t get missing translation violations from the lint checks during the development process.
- Building and uploading to the Play Store of release client are handled by the CI system after merging changes into the
It turned out that we need a solution which meets the following requirements:
- Building release client should fail if translations are missing;
- Regular CI builds shouldn’t fail due to lint violations, so we can continue to gather lint stats from it;
- Local builds should fail due to lint violations so we can fail fast and avoid pushing code with serious lint issues into the CI system.
And here the ability to pass command line arguments comes handy. Turns out that we need to set the
abortOnError value to
false only for the CI jobs related to pull requests. For other cases like local and release builds setting the
abortOnError value to
true is perfectly fine. So we can modify
And execute the following command for the CI jobs triggered by pull requests:
So now we can control if our build is going to fail due to lint violations or not. But we are still missing something — release build won’t fail because of missing translations since we downgraded the severity of
MissingTranslation check to just a warning. And here is the last trick — before building the release version we can modify
lint.xml and remove mentioning of the
MissingTranslation check using grep:
Now everything is in place and if there are any missing translations — application just won’t compile and won’t be uploaded to the Play Store, while we still can enjoy our lint statistics graph and don’t be blocked by missing translation during the development process.
I have one more example when specifying command line parameters helped me a lot in achieving the desirable result. It’s not as interesting as the previous one, but still, worth mentioning. Some time ago I had to use splits feature in order to build different
APKs for different
ABIs. The issue was that it was quite expensive in terms of compilation time. Then I realised that splits are needed only for the release build and it’s is not necessary to add them to my regular build process to avoid increasing precious compilation time. All we need to do for solving this issue is just to introduce a command line argument to
And build a release version with the following command:
As you see, even a simple trick like passing a command line argument to your build script can help you automate some things that will save hours of your time and make your builds less error-prone.