Re: Need a builtin way to run all tests faster manner

From: Jim Nasby <jim(dot)nasby(at)openscg(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Need a builtin way to run all tests faster manner
Date: 2017-03-10 19:53:12
Message-ID: 136a4e9d-32c0-961f-46a3-dc1dde233c69@openscg.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/10/17 1:09 PM, Peter Eisentraut wrote:
> On 3/10/17 03:27, Jim Nasby wrote:
>> Perhaps https://travis-ci.org/ or something similar could be used for
>> this. That avoids any issues about random code.
>
> That doesn't achieve any platform coverage, which is the main point here.

I don't think platform coverage is the first thing to worry about with
patches, nor with ongoing development.

The biggest win we'd get from something like Travis would be if the
commitfest monitored for new patch files coming in for monitored threads
and it created a new branch, applied the patches, and if they applied
without error commit the branch and push to let Travis do it's thing. We
wouldn't want that running in the main git repo, but it should be fine
in a fork that's dedicated to that purpose.

If the travis build failed, commitfest could notify the author.

It could also rebase master into each branch on a daily basis so authors
would know very quickly if something got committed that broke their patch.

Obviously that doesn't remove the need for manual testing or the
buildfarm, but it would at least let everyone know that the patch passed
a smoke test.
--
Jim Nasby, Chief Data Architect, OpenSCG
http://OpenSCG.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-03-10 19:57:00 Re: ANALYZE command progress checker
Previous Message Andres Freund 2017-03-10 19:49:46 Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)