Heya Bastian, if they are still relevant, here are a few answers for the “Open Questions” in the README:
> There is no CentOS/RHEL there, shouldn't it be added? Yes it should. > Do we run a CouchDB build on all combinations on each commit? This would > probably be too much for the ASF Infra build systems. Do we build them once a > day? We need to find a good balance between early feedback and resource > consumption here. Eventually, I would like a build in all combinations on all commits and all PRs / branches (unless a branch opts out proactively). I’m sure we can drum up the computing resources required, when we need them. For the time being, I’m happy with whatever in-between, as long as we have some CI :) > Do we even want to build the master branch or some other branch/tag? I guess > the master branch would be most interesting for now, but not entirely sure. > Also, it might make sense to make the branch/tag parameterizable so we could > also use this to create releases from a specific tag etc. Yup, I’d love this. Ideally, we only ever vote on releases that come from a CI’d release channel and eventually declare one a stable release instead of handcrafting tarballs. > What exactly do we do in each Jenkins build? Just build CouchDB? Also build > docs? Start CouchDB? Run some test suite? I think we covered this earlier in the thread. > The build is currently triggered as the CMD in the Dockerfile via the script > build-ci.sh. Is that okay? If we need more steps (beyond simply building > CouchDB) we would need to add it to build-ci.sh. Sounds okay to me. Best Jan -- > On 24 Dec 2015, at 23:37, Bastian Krol <bastian.k...@tu-dortmund.de> wrote: > > Hi folks, > > > > I fixed one more issue that prevented us from building CouchDB from within > > a release tarball > > this line from Jan in the release testing thread reminded me of another > question I pondered for the CI topic. > > Right now we clone/update the repo from git and then run "./configure && make > all check dist" and that's it. I wonder if that is enough? Currently I am not > doing anything with the binary or the tarball that is produced in this step. > > My guess would be that the one following would yield a more valuable feedback: > > * Start CouchDB via the binary that has been produced by make all and at > least run some simple smoke tests against that instance -- or is something > like that done during make all/make check? > * Or, run make dist first to only produce a tarball, then use that tarball to > actually build the CouchDB binary - instead of building directly from the git > checkout. (This would catch the kind of issues mentioned by Jan above, I > suppose). > * Some combination of the above, for example, build the binary from a dist > tarball, start it, run smoke tests. > > > What do you think? > > > Disclaimer: I didn't take the time yet to really check the Makefile (and also > my make skills are close to non-existing), so if the Makefile already covers > parts of this, my bad. > > > Kind regards, merry Christmas & happy holidays > > Bastian
