Enable travis about phidgets_drivers

[jack-oquin]

No problem, except that the new repo is not showing up yet on Travis CI. I'll check it again later.

[jack-oquin]

Never mind, I just told it to sync with github. I think it should work, now.

[mintar]

Thanks, looks good!

[tfoote]

@mintar is there a reason you'd rather use travis instead of the devel jobs on build.ros.org like: http://build.ros.org:8080/job/Idev__phidgets_drivers__ubuntu_trusty_amd64/?

[mintar]

Note: This became a longer rant than expected. Please take it as constructive feedback. I really appreciate all the work you guys put into build.ros.org, it's just that I feel Travis still has a couple of advantages at the moment.

---

Several reasons (please correct me if I'm wrong here):

1. It doesn't build pull requests, feature branches or forked repos.
2. It lacks GitHub integration.
3. It doesn't distinguish between "errored" and "failed" states.
4. It likes to get stuck in a failed state, and you cannot manually trigger a rebuild.

(1): I think the overarching theme here is that I really like a clean git history. That means only things that pass the CI checks should end up in the main development branch. Since the build.ros.org jobs only run once a commit has landed in the main development branch, it's too late by then. I can enable Travis on my personal fork of a repo with a single click, so when it catches a compilation error, I can rebase and force-push to my personal repo until everything works before pushing to the main repo, without having lots of "fix compilation error" commits mixed in. Other people's PRs are also checked.

(2): This doesn't matter right now, since the devel jobs don't build PRs. If a job fails, I get an email, and since there is only one branch it's easy to know which branch fails. But once it would build PRs and feature branches, it's essential to see at one glance which branches and PRs fail and which pass.

(3): Travis distinguishes between an "errored" state (i.e., an error in the install section of travis.yml) and a "failed" state (i.e., an error in the script section); see here for an example. When a build fails due to network problems when connecting to the Ubuntu or ROS mirrors etc., it goes to "errored", and I know that I probably just have to wait a couple of minutes, retrigger the build and it will pass, whereas a "failed" state means something is wrong with my code. On build.ros.org, I have to scroll through thousands of lines of log output just to see that it wasn't my fault after all.

(4): Case in point: Jdev__katana_driver. Apparently I created the devel job when ros-jade-gazebo-ros was not released yet. If the job were retriggered now, it would build fine. But the only way to do that would be to push a dummy commit, which I don't like to do. The Travis web interface has a button for that.

Another advantage is that you can customize the build process. For example, volksbot_driver requires a PPA, which you can do in the travis.yml. I wouldn't count this as a point against the devel jobs though, because requiring a PPA means that the package cannot be released anyway. In fact, this is the only reason we haven't released volksbot_driver yet, although it would be useful for many people.

[jack-oquin]

I agree that Travis is great, and have gradually been using it with more github repositories. Before its use became so common, the devel jobs served a more crucial function.

I guess there are still problems for Kinetic because Travis does not directly support Xenial. I understand that docker is an option, but have not yet climbed the learning curve for using that.

[tfoote]

@mintar I guess we need to make people more aware of the features we added. We do have support for pull-request building, with github integration, and retriggering via github comment.

How to setup PR builds: http://wiki.ros.org/buildfarm/Pull%20request%20testing
Here's all the configured ones for kinetic: http://build.ros.org:8080/view/Kpr/
They have Github integration (see the green checkmark on the 2nd attempted commit): ros/angles#9
You can retrigger them by asking @ros-pull-request-builder retest this please

Indeed we do want to distinguish between the error during setup vs error/failure during the run. ros-infrastructure/ros_buildfarm#119 Though we attempt to catch any known repeated failures, abort the build, and retrigger it. We've worked hard to bring our false failure rate way down. If there's any instance of a false failure we'd appreciate a ticket for us to track it.

[mintar]

Hi @tfoote , that is awesome. Looks like all the important points I criticized have already been adressed. Combined with the ability to test Kinetic, the build farm now looks to be even better than Travis. I'll give the build farm another go!