Re: [HACKERS] Need a builtin way to run all tests faster manner - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: [HACKERS] Need a builtin way to run all tests faster manner |
| Date | |
| Msg-id | CABUevEzebYkENo5BmO_oPnH868gBR968n8qZzQZFfApyjqOtcA@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] Need a builtin way to run all tests faster manner (Jim Nasby <jim.nasby@openscg.com>) |
| Responses |
Re: [HACKERS] Need a builtin way to run all tests faster manner
(Jim Nasby <jim.nasby@openscg.com>)
|
| List | pgsql-hackers |
On Fri, Mar 10, 2017 at 3:11 PM, Jim Nasby <jim.nasby@openscg.com> wrote:
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...
Yes. It's a pure mirror script.
I'm pretty sure we *don't* want to push a branch for every single patch that goes in a CF all into our master repository...
We could use a completely separate repo on github for it if we want, yes. Then we just need to figure out how to get the patches there..
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.
This is what I'm not so sure about. Setting up an empty container provided we only ever need to test the one thing and only ever need the one platform is not particularly complicated.
But if you can put together something that picks up the individual patches out of the mail threads in the CF app and keeps branch-tips in a git repo up-to-date with those, including feeding the results back into the app, then go for it :)
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.
Right. But people don't use that all the time, and it's not currently a requirement on patch submitters. and we've traditionally been of the opinion that we don't want to put too much requirements on such things for submitters.
Even if we can't make it work for really complicated patches it might still be a win.
Definitely as long as we can keep some manual process for thos epatches.
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.
Right.
//Magnus
pgsql-hackers by date: