Re: [PATCH v16] GSSAPI encryption support

On Fri, Jun 8, 2018 at 9:00 AM, Nico Williams <nico(at)cryptonector(dot)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 <rharwood(at)redhat(dot)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