On 24.08.2015 08:54, Marius Vollmer wrote:
Peter <petervo(a)redhat.com> writes:
> PROS:
>
> - It works and uses a newer OS (Ubuntu 14)
> - Allows you to ssh into instances to run / debug tests.
This is very, very nice.
> CONS:
Obviously another big con is that this stuff is not Open Source. These
are proprietary services. But so is GitHub. But until we have more
resources, and/or an open source hosted CI service ... we'll probably
have to ignore this con.
> - There is only one configuration per project that is configured
via
> their website. So you can't change the commands on a per branch / PR
> basis.
We could have a script in our sources that does all the work and
configure semaphoreci to just run that script. Would that work?
> - We have to run on their container based beta platform as their normal
> platform doesn't fully support inotify and causes tests to fail.
This is weird. How do they manage to not fully support inotify? Is it
a weird/broken filesystem? Some absurdly low limits somewhere?
NFS.
> - Doesn't do IRC notifications out of the box. Though we
could probably
> implement something using webhooks if we wanted to.
Personally, I didn't find the notifications very useful.
> What does everyone think about switching? Worth doing or should we
> keep looking at other options?
Right now the options are containers in either Semaphore or Travis,
right? (Which means we need to adjust the tests that need sudo, right?)
sudo can run in a container. It's just the Travis containers that don't
allow this. Presumably because it's easier to break out of a container
if you have root.
And switching to containers in Travis might just make the weird
"write
error" bug disappear, I guess.
But more importantly the Travis containers have an ancient operating
system (from 2012) and can't be updated (due to no root access).
But since you have done the work, and Semaphore has the
"ssh" killer
feature, I vote to switch to Semaphore.
Me too.
Stef