Hi backend monorepo engineers,

We're upgrading gradle version from 3.4 to 4.7. The aim is to increase the build performance in general; specifically, to enable other tools to build the monorepo.
You may want to check gradle docs for deprecations and potential breaking changes. We've tested these cases, and so far everything is working well.
There are some things to be noted, though:

-Xmx jvmargs is now set to 10g.

It should be enough in the (tested) common cases, you can try them yourself.
If you need a bigger value for your tasks, please do only in your own tasks.
P.S.: CodeBuild, CircleCI, and TravisCI don't currently offer builders with more than 16GB of RAM

declaring annotation processor dependencies (based on gradle docs and gradle 4.6 release notes) is now either:

annotationProcessor project(":frontend-fx:api-ap")

we suggest you to switch to this standard way to define project dependencies

annotationProcessor "com.traveloka.common:lifecycle-ap:1.0.0"

generating global.lock

it is now to be done in laptop, again

We used a gigantic build instance in jenkins as a dirty workaround to generate this file
With the new gradle and plugins versions, you should now be able to generate it locally without any hassle
Try it! ./scripts/generate-global-lock.sh

cleaning your dependencies.

Our monorepo is growing larger, and faster. In addition to the gigantic repository size, the unclean (undeclared transitive, excessively declared) dependencies, is responsible for slow builds, and loads; fully, or partially
Doing stuff partially might get the jobs done faster, for now, but it also depends heavily on how you declare your dependencies
having efficient dependencies will later help to move the codes out of the monorepo easier & faster
So please, do declare your dependencies efficiently.

delete old phabricator tags from your laptop

it was not set to be cleaned up automatically during previous phabricator & jenkins firefighting action, but now it is
git fetch --prune origin +refs/tags/*:refs/tags/*

Last but not least, upgrading gradle versions for a repository with 200+ services takes quite some time and will take longer in the future. We hoped this will be the last centralized gradle upgrade for the monorepo as we're putting our focus to explore the multiple git repositories approach

Backend-monorepo gradle version upgrade