couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: What to run/test during a CI build
Date Sun, 27 Dec 2015 18:48:04 GMT
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
Is that okay? If we need more steps (beyond simply building CouchDB) we would need to add
it to

Sounds okay to me.


> On 24 Dec 2015, at 23:37, Bastian Krol <> wrote:
> Hi folks,
> > I fixed one more issue that prevented us from building CouchDB from within a release
> 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
> * 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

View raw message