If some of the tests are too strict, should we move it to be triggered on a different branch? For example, fails come only on master, while they show up as "warning" for other branches and we build --force incase of other branches?
-----Original Message----- From: Josh Soref [mailto:[email protected]] Sent: Wednesday, August 20, 2014 8:00 AM To: [email protected] Subject: Re: continuous integration woze On 8/20/14, 10:50 AM, "Mark Koudritsky" <[email protected]> wrote: >AFAIK Travis only supplies a binary pass/fail status, so there is no >such thing as a warning. >A Travis check for pull request doesn't mark the entire build on master >as failed, only that pull request. So there is no need to panic and >"drop everything and fix the build", instead just "fix the build" by >updating the pull request :) Fwiw, I thought that I had pushed an update to the pull request, but apparently my `git commit —amend` was missing a `-a`, and thus my `git push -f` didn't do anything useful. >That said, I would be glad if Travis was commenting on pull request >with a line or two rather than just setting the binary pass/fail >status. This would also be a great feature for using multiple CI >services like we do with Travis and AppVeyor. Anybody knows if Travis >can be configured to leave comments under pull requests? I would much prefer this, because as is, I have at least 4 "outputs" from travis+appveyor, and yet if you look at the pull request, you'll only see one.
