On 26/09/2011, at 4:16 PM, Merlyn Albery-Speyer wrote: >> * We're making a performance-accuracy trade-off here. Which means we'll >> probably need some way to tweak the behaviour. Not sure exactly how this >> might look, yet. I'd start with a simple time-to-live property on each >> configuration, and let the use cases drive anything beyond that. > > How about a triggered build on a CI server with the triggered project > using a dynamic revision to reference the project that triggered it?
A good question. In some ways, it seems like it's the responsibility of the CI server to tell me exactly which revision to use, rather than using a dynamic revision, from a reproducibility point of view. > To me that's most cleanly addressed by using all resolvers for dynamic > revisions as you suggest. We'd also have to skip the cache in this instance, too. Or, more accurately, we'd need to verify that the cached artifacts are actually the latest. That is, we would need to go off to the repositories to do some kind of lookup. Verifying the cached artifacts doesn't necessarily mean we need to download the artifacts - just compare the hash of the local artifacts with that in the repository. The question is, how do we decide when we need to verify a cached dynamic revision, and when we can just use the cached value without checking? Is it a function of the type of build? That is, if I'm doing a CI build, should I verify all dynamic dependencies, whereas if I'm doing a dev build, should I just check for changes once a day? Or is it a function of the dependency? That is, should I verify dependencies on group 'org.gradle.*' every time I build, but check all other dynamic dependencies once a day? Or is it a function of my location? That is, if the corporate repository is reachable, then check on every build, otherwise just use what's available? > >> * For dynamic revisions, stopping on the first resolver means we may miss a >> newer revision that happens to be in a later repository. An alternate >> approach might be to use all resolvers for dynamic revisions, but only when >> there is no unexpired value in the cache. We could do this search in >> parallel, and just pick the latest out of those we have found at the end of >> some timeout. Perhaps we could do the search in parallel for all revisions, >> dynamic or not. > > If more than one network-based resolver is likely to perform a search, > it makes good sense to me that those searches be in parallel. > > Once an artifact is served from a particular repository, a newer > version of it is commonly served by the same repository. That > information could be used to alter the search order - although that > could admittedly hurt the determinism of builds, especially if the > resolution strategy does not search using all resolvers. Right. I'm thinking more and more that we should search all repositories for dynamic revisions. Which means it doesn't really matter which order we use them. It's the latest strategy's job to decide which actual revision to use. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
