Running Beaker tests in a Public CI

[Peter M Souter]

Hi all!

So I saw Gareth's talk on Continuously testing infrastructure talk at Puppetconf, I saw that wercker has docker support. 

I'd seen a few people hack together docker support in Travis, but it was a bit hacky (https://github.com/lukecyca/travis-docker-example) and whilst there seems to be plans for easy integration with docker in Travis at some point, it's not setup right now (https://github.com/travis-ci/travis-ci/issues/1418)

But, it seems fairly easy in wercker: https://github.com/petems/puppetlabs-inifile/blob/wercker_setup/wercker.yml

Here's puppetlabs-inifile running all the Acceptance tests in a deb7 docker container: https://app.wercker.com/#build/54289601343c00937204cbaf

I know PuppetLabs themselves use their own Jenkins server with Virtualbox on it, but for those who want to get beaker stuff up publicly easily and (for now, free) wercker seems to work pretty well! :)

Thanks

Regards

[Ken Barber]

> I know PuppetLabs themselves use their own Jenkins server with Virtualbox on
> it, but for those who want to get beaker stuff up publicly easily and (for
> now, free) wercker seems to work pretty well! :)

Actually, we generally use VSphere now (I presume you mean just module
testing), just FYI. We also have a small smattering of EC2 for other
projects, but most of our stuff is VSphere afaik.

ken.

[Peter M Souter]

Actually, we generally use VSphere now (I presume you mean just module
testing), just FYI. We also have a small smattering of EC2 for other
projects, but most of our stuff is VSphere afaik.

ken.

Ah ok, yeah I was talking mainly about module testing. But yeah, the general gist is if you want to run beaker tests for free and in a public CI, Werker + Docker seems to work :) 

[Trevor Vaughan]

How does running tests with SELinux contexts work in a Docker instance? (I'm not guessing very well, but it would be nice to have confirmation).

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/a99c9789-0cb3-4f6a-94aa-c3e08e2400e3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Ken Barber]

> Ah ok, yeah I was talking mainly about module testing. But yeah, the general
> gist is if you want to run beaker tests for free and in a public CI, Werker
> + Docker seems to work :)

Yeah absolutely, it's an exciting way of doing tests really. There are
some exceptions of course - for example if you rely on testing
anything in the kernel docker isn't the best choice since a container
uses its parents kernel ... puppetlabs-firewall is an example of this
since it relies on iptables features in the kernel of the distro to be
tested correctly. But for most modules a docker/lxc-style test is
brilliant and fast.

ken.

[Dominic Cleal]

On 01/10/14 15:27, Trevor Vaughan wrote:
> How does running tests with SELinux contexts work in a Docker instance?
> (I'm not guessing very well, but it would be nice to have confirmation).

I think the way it works recently (since Dan Walsh's work around Docker
0.10/11) is that /sys/fs/selinux is read-only inside the container, and
libselinux understands this as "SELinux is disabled".

As far as selinuxenabled etc are concerned, there's no SELinux support,
so the same as running on a normal host or VM without SELinux enabled.

(This is separate to whether SELinux is functional on the host running
the container.)

https://bugzilla.redhat.com/show_bug.cgi?id=1096123 has some interesting
background, as EL6's libselinux didn't understand what the read-only
/sys/fs/selinux mount meant.

--
Dominic Cleal
Red Hat Engineering