BuildCacheServiceFactory.Describer should preserve the order of config values

[vlsi]

Expected Behavior

The order of elements should be preserved when calling org.gradle.caching.BuildCacheServiceFactory.Describer#config(String, String) multiple times.

Current Behavior

Gradle shuffles the items as the implementation is using HashMap:

gradle/subprojects/core/src/main/java/org/gradle/caching/internal/services/BuildCacheControllerFactory.java

Line 248 in 0740507

private Map<String, String> configParams = new HashMap<>();

Context

I need to configure multiple remote build caches for Gradle, and the order of the caches is important. Unfortunately, Gradle shuffles the values in Build Scan output which makes the analysis harder.

Your Environment

https://scans.gradle.com/s/ew2s77ylxhif2/performance/buildCache#remote-cache-configuration

[wolfs]

@vlsi Would you be willing to provide a PR for this?

[vlsi]

I think I can do that. I know you prefer end-to-end tests, however, I'm not sure I would be able to create one in this case.

[wolfs]

Actually, the configParams are converted into a sorted map:

gradle/subprojects/core/src/main/java/org/gradle/caching/internal/services/BuildCacheControllerFactory.java

Line 161 in e062ebd

ImmutableSortedMap<String, String> config = ImmutableSortedMap.copyOf(describer.configParams);

So the order is not random at all. Does that mean we can close this issue?

[vlsi]

Should it better preserve the order of the original arguments?

[ldaley]

@vlsi Can you explain why you think order preserving would be better? What would you use this for?

[vlsi]

My use case is to create a proxy build cache which is a build cache implementation that delegates the calls to multiple downstream build cache services.

The order of calls is important, so the users see which cache would be requested the first, and which one would be requested later.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.