On Fri, Jun 8, 2018 at 9:00 AM, Nico Williams <n...@cryptonector.com> wrote: > On Tue, Jun 05, 2018 at 12:16:31PM +1200, Thomas Munro wrote: >> On Sat, May 26, 2018 at 6:58 AM, Robbie Harwood <rharw...@redhat.com> wrote: >> > Me and the bot are having an argument. This should green Linux but I >> > dunno about Windows. >> >> BTW if you're looking for a way to try stuff out on Windows exactly >> the way cfbot does it without posting a new patch to the mailing list, >> I put some instructions here: >> >> https://wiki.postgresql.org/wiki/Continuous_Integration >> >> The .patch there could certainly be improved (ideally, I think, it'd >> run the whole build farm animal script) but it's a start. > > Cool! Is there any reason that your patch for Travis and AppVeyor > integration is not just committed to master?
I think that's a good idea and I know that some others are in favour. The AppVeyor one is not good enough to propose just yet: it's cargo-culted and skips a test that doesn't pass and only runs the basic check tests (not contribs, isolation, TAP etc). Fortunately Andrew Dunstan has recently figured out how to run the official build farm script inside AppVeyor[1], and it looks like we might be close to figuring out that one test that doesn't work. That makes me wonder if we should get the Travis version to use the build farm scripts too. If we can get all of that sorted out, then yes, I would like to propose that we stick the .XXX.yml files in the tree. Another thing not yet explored is Travis's macOS build support. Someone might argue that we shouldn't depend on particular external services, or that there are other CI services out there and we should use those too/instead for some reason, or that we don't want all that junk at top level in the tree. But it seems to me that as long as they're dot prefixed files, we could carry control files for any number of CI services without upsetting anyone. Having them in the tree would allow anyone who has a publicly accessible git repo (bitbucket, GitHub, ...) to go to any CI service that interests them and enable it with a couple of clicks. Then cfbot would still need to create new branches automatically (that is fundamentally what it does: converts patches on the mailing list into branches on GitHub), but it wouldn't need to add those control files anymore, just the submitted patches. > Is there a way to get my CF entry building in cfbot, or will it get > there when it gets there? Urgh, due to a bug in my new rate limiting logic it stopped pushing new branches for a day or two. Fixed, and I see it's just picked up your submission #1319. Usually it picks things up within minutes (it rescans threads whenever the 'last mail' date changes on the Commitfest web page), and then also rechecks each submission every couple of days. In a nice demonstration of the complexity of these systems, I see that the build for your submission on Travis failed because apt couldn't update its package index because repo.mongodb.org's key has expired. Other recent builds are OK so that seems to be a weird transient failure; possibly out of data in some cache, or some fraction of their repo server farm hasn't been updated yet or ... whatever. Bleugh. > I know I can just apply your patch, push to my fork, and have Travis and > AppVeyor build it. And I just might, but cfbot is a neato service! Thanks. The next step is to show cfbot's results in the Commitfest app, and Magnus and I have started working on that. I gave a talk about all this at PGCon last week, and the slides are up[2] in case anyone is interested: [1] https://www.postgresql.org/message-id/flat/0f3d44a1-1ac5-599c-3e15-16d058d54e9a%402ndQuadrant.com [2] https://www.pgcon.org/2018/schedule/events/1234.en.html -- Thomas Munro http://www.enterprisedb.com
