You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rya.apache.org by "Aaron D. Mihalik" <aa...@gmail.com> on 2016/10/20 21:45:16 UTC

Move to Travis-CI?

Devs,

We now have Jenkins (builds.apache.org) building master and all PRs. This
is awesome, but I think we could do a bit more.

How do you all feel about moving to Travis-CI? It seems like it'll give us
more functionality than Jenkins, many other Apache projects use it, and
it'll be more reliable than builds.apache.org. However, it'll require a
special request to INFRA.

Specially, the purpose of moving to Travis-CI would be to gain more
information about our code base, it's "health", and how PRs coming in may
effect it. I think Travis-CI has a couple of key features:

- Travis-CI builds all branches and PRs, and maintains all of the history
(no artifacts) for those builds. Right now Jenkins will only retain the
last few builds across all builds. This is kinda annoying if you want to
investigate why an older PR failed.

- Travis-CI integrates with other tools (eg coveralls.io) that will allow
us to track and explore other facets of our code (coveralls does code
coverage). It seems like Apache supports coveralls, but there are other
integrations (eg coverity scan) that might be useful as well.

- Travis-CI provides a nice dashboard for looking at the build history for
the project.

What do you all think? I'm new to Travis-CI and many of these other tools,
so if someone else has more experience, please chime in.

Thanks,
Aaron

Re: Move to Travis-CI?

Posted by Josh Elser <jo...@gmail.com>.
(disclaimer, I really have no opinion at all about which system is used, 
just providing context)

Aaron D. Mihalik wrote:
> Devs,
>
> We now have Jenkins (builds.apache.org) building master and all PRs. This
> is awesome, but I think we could do a bit more.
>
> How do you all feel about moving to Travis-CI? It seems like it'll give us
> more functionality than Jenkins, many other Apache projects use it, and
> it'll be more reliable than builds.apache.org. However, it'll require a
> special request to INFRA.

Travis is not wholly more reliable than Jenkins on builds.a.o. If a 
build starts failing on Travis, you pretty much have no remediation at 
all. At least with Jenkins, you have some escalation because they are 
machines that the ASF controls.

> Specially, the purpose of moving to Travis-CI would be to gain more
> information about our code base, it's "health", and how PRs coming in may
> effect it. I think Travis-CI has a couple of key features:
>
> - Travis-CI builds all branches and PRs, and maintains all of the history
> (no artifacts) for those builds. Right now Jenkins will only retain the
> last few builds across all builds. This is kinda annoying if you want to
> investigate why an older PR failed.

This might just be configuration on retention? You should have the karma 
to modify the job to change the number of jobs retained. Or someone with 
VP karma could grant it to you.

Not sure if you have it wired up, but the ASF Jenkins can also be 
configured to build PRs and report back to GH. Not clear to me if you 
knew about that.

> - Travis-CI integrates with other tools (eg coveralls.io) that will allow
> us to track and explore other facets of our code (coveralls does code
> coverage). It seems like Apache supports coveralls, but there are other
> integrations (eg coverity scan) that might be useful as well.

If a Jenkins plugin exists, INFRA can be bothered to try to get them to 
install it. INFRA may object depending on the stability of the plugin 
though.

> - Travis-CI provides a nice dashboard for looking at the build history for
> the project.
>
> What do you all think? I'm new to Travis-CI and many of these other tools,
> so if someone else has more experience, please chime in.
>
> Thanks,
> Aaron
>