> -----Original Message----- > From: crowbar-bounces On Behalf Of Adam Spiers > Sent: Monday, March 11, 2013 7:28 PM > To: crowbar > Subject: Re: [Crowbar] how to debug Travis failures > > Adam Spiers (aspi...@suse.com) wrote: > > I'm really keen that I (or James, or anyone else) don't become the > > bottleneck on Travis builds. I really think it needs to be a > > team-wide responsibility, e.g. if anyone sees test failures and thinks > > they may have caused them, that they take the lead in resolving them.
Yup.. as you might notice from the latest set of activity, there's been a concerted effort to fix the test failures. One thing that caused some confusion is the distinction between: a) the machinery that runs the tests - i.e travis itself, b) the update-git cron job, and its activities c) the actual test failures. AFAIK: we're not going to mess with travis proper :), so that takes care of a). update-git ( b) above. If I understand correctly, you have it covered - in some remote corner of your lab there's a server that dutifully runs this on a 5 minute interval? At this point, we're not running a similar process, making your server the only trigger for updating the travis repo. (so if it was running on your laptop and you went home for the weekend, no tests will be triggered till you were back ;). Should we setup a mirror of this process, to avoid a SPOF? It appears relatively safe to run multiple copies - or do you suspect that Bad Things will happen (e.g. the 2 instances resulting in some sort badness ?). It appears that the script does a 'git push -f' so merge conflicts are not likely. As for c)... yes. Definitely. I think we've been doing that. > > That's especially true right now based on the other mail I just sent > > to the list, since we're in a situation where pull requests are not > > automatically tested prior to merge, and consequently trunk is at much > > higher risk than it should be. > > > > To this end, I have already spent quite a bit of effort trying to > > ensure that the whole testing setup is properly documented in a way > > that everyone can understand, e.g. > > > > https://github.com/crowbar/crowbar/blob/master/doc/devguide/testing/tr > > avis.md > > https://github.com/crowbar/crowbar/blob/master/doc/devguide/testing.md > > > > That said, I do admit that it is currently missing a "how to > > troubleshoot Travis test failures" section, and that is a sore > > omission - thanks for helping me realise that! However I have no time > > to write this since I have to start preparing the rspec talk for > > tomorrow, and anyway, I think I've done far more than my fair share of > > documentation work recently ;-) So can I suggest that someone else > > take ownership of writing this, and use it as a good exercise in > > learning about the Travis builds in the process? Shouldn't be a big > > job, and of course I'm happy to answer any questions which may arise. > > Oh well, for some reason I ended up doing this myself %-) > > https://github.com/crowbar/crowbar/pull/1747 > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
