On Fri, Oct 13, 2017 at 1:50 AM, William Roberts
<bill.c.roberts@xxxxxxxxx> wrote:
> On Thu, Oct 12, 2017 at 1:48 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
>> On Thu, 2017-10-12 at 11:29 -0700, William Roberts wrote:
>>> I see a travis.yml file, recently modified by Nicolas, but I failed
>>> to
>>> find the Travis CI instance on travis.org, where is it?
>>>
>>> We should likely have it running on commits to the repo and PRs so we
>>> can have some independent way of verifying that our run of the tests
>>> was compromised by some env variation or mistake.
>>>
>>> Thoughts?
>>
>> To date he has just run it on his own fork. Not opposed to enabling
>> it, just haven't looked into that...
>
> I have done it for my some of my projects, Ill go ahead and set this up.
I configured Travis-CI to test the branches in my Github repository a
little more than one year ago, after several build configurations got
broken (clang on Linux for example). I later added more features to it
(for example warning about missing .gitignore entries, testing several
Ruby and Python versions, etc), before I upstreamed my .travis.yml
file (a few months ago). When I did it, my main motivation was to
simplify the job of anyone who would want to configure a CI system on
the project (the building rules and dependencies should be quite
similar). Using a continuous integration system is useful to prevent
simple regression issues which would otherwise only be detected when
someone running a specific configuration tries to build the project.
Before asking to enable Travis-CI on the main SELinux repository, I
wanted to make sure it was stable/reliable enough. To do this, I
created a branch named "travis-upstream" in my repository, which
tracked the master branch of the main repository. All went well for
quite some time, until Travis-CI modified this summer their
environments, introducing some incompatibilities with projects which
use several programming languages. Thankfully these changes have been
documented in Travis-CI's blog and I updated the config file to fix
the builds with commits b1ea8120832d ("Travis-CI: use sugulite
environment") and 6d9258e5a05f ("Travis-CI: fix configuration after
September's update"). As Travis-CI does not seem to want to support
multi-language projects (cf.
https://github.com/travis-ci/travis-ci/issues/4090 for example), more
breaking changes could be introduced as the provided environment are
upgraded. Nevertheless I expect that such changes are quite easily
fixable.
In short, using a CI platform is useful and Travis-CI is a free one
which makes it possible to test several build configurations (I also
tried Circle-CI, which did not provide a similar feature) and
maintaining a working configuration does not require much effort.
Moreover when a Travis-CI job fails, the log contains the console
output which usually is very clear about what has gone wrong.
Travis-CI now also provides Docker images which help reproducing
issues and understanding their cause without needing to submit a new
job.
If you want to set this platform up for SELinux userspace project,
please go ahead :)
Cheers,
Nicolas
