Error 52, which if it lines up with what I am reading is CURLE_GOT_NOTHING https://curl.haxx.se/libcurl/c/libcurl-errors.html That url/command combo seems valid, likely a transient issue with github. On Tue, Oct 24, 2017 at 9:05 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Wed, 2017-10-18 at 19:30 -0700, William Roberts wrote: >> On Tue, Oct 17, 2017 at 12:50 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> >> wrote: >> > On Tue, 2017-10-17 at 11:49 -0700, William Roberts wrote: >> > > On Sun, Oct 15, 2017 at 5:10 AM, Nicolas Iooss <nicolas.iooss@m4x >> > > .org >> > > > 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@tycho.n >> > > > > sa.g >> > > > > ov> 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. >> > >> > Enabled now for the selinux repo. >> > >> >> FYI this is up and running thanks to Nicolas's .travis.yml. >> >> You can see it verifying this PR >> https://github.com/SELinuxProject/selinux/pull/66 >> >> I've submitted that patch to the mailing list as well. > > Our .travis.yml seems to yield unstable results, > https://travis-ci.org/SELinuxProject/selinux/jobs/292128434 > > Don't know if it would help to instead download a refpolicy release and > extract it, or if this is just transient. > -- Respectfully, William C Roberts
