[crazy-max]

Replace the serialx/hashring dependency with a local implementation for sticky pod selection. Buildx only uses the library to construct an unweighted ring and perform one lookup, so a single scan avoids allocating and sorting the ring while preserving existing context-to-pod assignments and cache locality.

The implementation retains the original hash ordering, exact-match and wraparound behavior, and random-chooser fallback when the initial pod list is empty. Compatibility was checked against the previous library across 64,000 selections, with permanent regression tests covering representative assignments, pod removal, and fallback behavior.

[AkihiroSuda]

a single scan avoids allocating and sorting the ring

Do you have benchmark data?

[crazy-max]

Yes, I compared the previous hashring implementation against the new scan, including ring construction on every call. Both use the same pod filtering and sorting code, with an in-memory pod list replacing the Kubernetes API request.

These are medians of six runs:

Pods	Old ns/op	New ns/op	Old B/op	New B/op	Old allocs/op	New allocs/op
1	1,924	1,188	1,656	656	31	16
3	3,064	1,693	2,216	736	47	20
10	7,441	3,179	5,824	1,040	97	29
30	19,289	6,450	17,953	1,616	208	50
100	52,754	17,097	47,778	4,400	568	122

The scan takes 38–68% less time in these measurements and allocates less at every pod count. Note that removing the dependency while preserving existing assignments is still the main benefit.