Re: [PATCH v16] GSSAPI encryption support - Mailing list pgsql-hackers

On Fri, Jun 08, 2018 at 10:11:52AM +1200, Thomas Munro wrote:
> On Fri, Jun 8, 2018 at 9:00 AM, Nico Williams <nico@cryptonector.com> wrote:
> > 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.

I use AppVeyor for Heimdal and for jq...  Maybe I can help out.

As for Travis' OS X support... the problem there is that their build
farm is very small, so using theirs means waiting and waiting.

> 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.

Carrying the .yml files causes no harm beyond dependence, but that's a
nice problem to have when the alternative is to not have a CI at all.

> 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.

You wouldn't need it to.  Instead the CF page could let submitters link
their CI status pages/buttons...

> > 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.

Thanks!

> 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.

Oof.

> > 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:

OK.  I think that will be a huge improvement.  I find CF to be fantastic
as it is, but this will make it even better.

Thanks,

Nico
--