Is there the possibility that based on the HTTP response code for artifact retrieval, we could invoke different behaviors on the next request for failed-to-download artifacts?
1) If we get an HTTP timeout for a request, it is cached as a "fail" today, and thus not tried again until a -U is explicitly passed in. 2) If we get a response of a 404 for an artifact, we also cache it as a "fail" and do not try it again until we get a -U. It seems like in the second case, that's the right thing to do. It seems like in the first case, we'd want to try it again next time we have connectivity. In short, a does-not-exist-404 is vastly different from a network timeout. The scenario that maps to this from one of my students is described as follows: QUOTED: I decide I need a new jar for my project. I quickly add the jar to my local repo and add it to my pom, and begin coding to make sure it's doing what I want it to do. Then I go and contact my release engineer to get the jar into our private repo. Well, now I go off and do more work on my class, and finally I'm happy, my tests work, and I submit. Oops! My release engineer hadn't gotten a chance yet to add my jar to the private repo, so now our build fails. So what now? My build still fails because of this caching. So what do we have to do? We have to change our build script to have the -U option to fix the problem. And this is just on one box, oh the pain when I have to track down which of my Hudson slaves this ran on and make sure that slave is the one that takes the next build. In the end this means I'll just have to stick the -U option on all of my builds, because it's less hassle when the scenario happens. Thanks in advance for your thoughts on this... -Matthew McCullough --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
