[Zlib-devel] Organizing zlib CI

[Chris Blume]

AppVeyor is not open source and also does not support all the platforms we
want to support such as POWER and Arm.
Because of this, it is only a stepping stone and not the end goal.

The end goal would likely be something like BuildBot, where we can control
which hardware gets used.

Chris Blume | Software Engineer | cblume at google.com | +1-614-929-9221


On Mon, Dec 9, 2019 at 12:10 PM Tulio Magno Quites Machado Filho <
tuliom at linux.ibm.com> wrote:

> Chris Blume <cblume at google.com> writes:
>
> > Backstory:
> > A few of us would like to add continuous integration (CI) to zlib.
> AppVeyor
> > seems to be our best bet at the moment. Eventually, we would like to
> > support more platforms such as Power and ARM. For that, we'll need a more
> > complicated infrastructure that we manage ourselves as part of zlib.
> > Starting with AppVeyor will help get the CI ball rolling.
>
> Is AppVeyor fully open source?
>
> As someone that is interested on POWER, I'm inclined to say this proposal
> is
> not ideal.  But I understand and agree with the issues on other CI
> solutions.
> Including the costs related to maintaining the services (HW and SW).
>
> Assuming that platforms (both architectures and OSes) that are not covered
> by AppVeyor will be able to test it outside of AppVeyor and still send
> failure messages, I'm fine with your proposal.  ;-)
>
> > Daniel Black had a great suggestion that we use CMake to create the
> Visual
> > Studio Solution that AppVeyor needs. I can then connect that VS Solution
> > and zlib's existing unit tests to AppVeyor's expected test result format.
> >
> > Daniel, does that work for you?
>
> --
> Tulio Magno
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://madler.net/pipermail/zlib-devel_madler.net/attachments/20191209/eb1c03b6/attachment.html>