On Sun, Oct 15, 2017 at 5:10 AM, Nicolas Iooss <nicolas.iooss@xxxxxxx> wrote:
> 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
>
I tried to turn it on in travis, but got the message:
This is not an active repository
You don't have sufficient rights to enable this repo on Travis.
Please contact the admin to enable it or to receive admin rights yourself.
Stephen maybe you can do this, or grant me the permissions?
You should be able to go here:
https://travis-ci.org
And login, and then in your organization for selinux flip the switch
for travis. Once it's on, and working, we can add the badge to the README
file for build status.
