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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers