Seems like we might be truncating the bits of the ID which would provide the most uniqueness (e.g., two Travis builds running simultaneously have the same time.time() seconds, and differ only in the last byte of the TRAVIS_BUILD_ID. Perhaps we should have unique_resource_id take a prefix argument and an optional max_length, and work out which bits to trim?

I don't think it's worth the effort. It's essentially impossible to end up with the same timestamp (it's YAGNI).

The version with TRAVIS_BUILD_ID in it truncates time.time() to an integer: if it is always unique, why do we need the TRAVIS_BUILD_ID at all?

why do we need the TRAVIS_BUILD_ID at all?

So we can track down the guilty build if we see un-cleaned up resources in the cloud console.

Won't that usecase be broken if we truncate off bytes from the build ID?

Ha! Touche. Easiest fix: I'll swap the order of BUILD ID and time. Anyhow, as it is there, the ID will be

>>>  len('gcloud-128927443-1462819431')
27
>>> len('new-128927443-1462819431')
24

so hopefully nothing will get truncated.

WDYT of just doing the swap?

WDYT of just doing the swap?

SGTM

@tseaver PTAL

LGTM