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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
