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

On 3/10/17 2:05 PM, Magnus Hagander wrote:
>
> Travis specifically would not help us with this, due to the dependency
> on gifhub, but something that knows how to run "patch ... && configure
> && make && make check" in a container would.

Who's updating https://github.com/postgres/postgres/ right now?
Presumably that script would be the basis for this...

> I'm unsure what would be easiest -- have something drive a "throwaway
> github repo" off the data in the CF app and try to pull things from
> there, or to just spawn containers and run it directly without travis.

I'd be a bit nervous about creating our own container solution and
opening that to automatically deploying patches. Travis (and other
tools) already have that problem solved (or at least if they get hacked
it's on them to clean up and not us :)

Plus it'd be a heck of a lot more work on our side to set all that stuff up.

> The bigger issue with those is the usual -- how do you handle patches
> that have dependencies on each other,because they're always going to
> show up as broken individually. I guess we could tell people doing those
> to just push a git branch on github and register that one in the CF app
> (which does have some very basic support for tracking that, but I doubt
> anybody uses it today).

If people use git format-patch it should JustWork(tm). Specifying a
specific repo is another option.

Even if we can't make it work for really complicated patches it might
still be a win.

> 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.
>
>
> It could at least verify that the patch still applies, yes.

If the rebase was pushed to github and travis was setup, travis would
then test the changes as well.
--
Jim Nasby, Chief Data Architect, OpenSCG
http://OpenSCG.com