On Wed, Feb 19, 2020 at 4:51 AM Ilya Khlopotov <iil...@apache.org> wrote: > > Sounds harder than I hoped. :-( >
I was a bit out of it yesterday so dunno if my email went through properly. Though I was trying to say the crazy docker bits should not be an issue. dev/run and eunit already have the smarts to start fdb if the fdbserver binary is available. We should be able to just add multi-stage docker builds that create the fdbserver binary and copy into our existing builds without much change to the existing stuff. foundationdb does take a while to build though, so finding binaries might short circuit everything to be even a single apt-get line or w/e. Though that papers over CentOS support and the like. Dunno what that story is like. > On 2020/02/18 20:06:48, Joan Touzet <woh...@apache.org> wrote: > > What Adam said. > > > > Reminder that to get CI builds working someone's going to need to do the > > legwork to add an FDB instance to the container-based build. I'm happy > > to grant docker hub credentials to couchdbdev for whomever takes this > > work on. > > > > -Joan > > > > On 2020-02-18 14:15, Adam Kocoloski wrote: > > > There’s nothing blocking us from using master for FDB development now > > > that we’ve got a 3.x branch — wouldn’t it be better to just make that > > > switch? > > > > > > Adam > > > > > >> On Feb 18, 2020, at 2:13 PM, Ilya Khlopotov <iil...@apache.org> wrote: > > >> > > >> Currently we only trigger CI on attempts to merge to master branch. With > > >> ongoing effort to rebase CouchDB on top of FoundationDB it seems like we > > >> would be running two projects in parallel for quite some time. The lack > > >> of CI on merge to prototype/fdb-layer causes merges of broken code. > > >> > > >> I am curious how hard it would be to enable CI for prototype/fdb-layer > > >> branch in addition to master branch. > > >> > > >> Best regards, > > >> iilyak > > > > >
