couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
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 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.krol@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


Mime
View raw message