This message was deleted.
# develocity
s
This message was deleted.
r
Hi @David Chang, we usually recommend you base it off of some gradle property that users can set in their gradle home properties file, and then use that to configure the cache's target node. What exactly you have them set depends on your setup, it could be the cache node address + credentials or something more abstracted like an enum.
d
I see, it's really difficult to get developers to opt in by themselves, and it would be better if GE can route for them
as we're becoming more distribute and have devs in South America, it's becoming more important that we can get devs better remote cache speeds
k
Don’t the GCP/AWS load balancers automatically connect you to the closest?
d
we have some of our devs that are getting 20-30 min builds with mostly remote cache hits, they'd be better off not using the remote cache, as our builds are <1 min
we currently don't have a load balancer, and was hoping for a solution from Gradle before looking into our own
👍 1
k
“In Premium Tier, you can deploy backends in multiple regions, and the load balancer automatically directs user traffic to the closest region that has capacity.” For GCP and for AWS: “*AWS* Global Accelerator continually monitors the health of your application endpoints, and automatically redirects traffic to the nearest healthy endpoints”
r
Don’t the GCP/AWS load balancers automatically connect you to the closest?
Yes, that's another option, most cloud providers nowadays have some sort of geolocation routing you can use. But there's nothing built into Gradle Enterprise
d
You probably just need latency/geo based DNS
r
@David Chang Another option is to derive it from some sort of user data, such as the locale, local time zone, username, etc. It's a bit of complication in the build logic, but avoids users having to specify anything