Default bool value for test_commits and test_pull_requests in rosdistro format

Question

REP-0143 defines test_commits and test_pull_requests (ashamedly I've never noticed these features. Looks so useful!). It's explained in this ticket that while default value of test_commits is false, ROS buildfarm overrides it as true. Why is that? Considering this feature is used mainly on ROS distro (correct me if wrong) then doesn't it make more sense to set true by default (then REP should state so)?

Also, my understanding is that test_pull_requests is by default false and remains as false on buildfarm. Why not turn it true? I haven't understood how to trigger the test based on this feature but assuming it's not automatically kicked for every PRs, turning it to true by default shouldn't harm anything?

Lastly, and most importantly, the usage of these parameters should be documented. In fact I'm willing to contribute, but where's the best location? --> (Update 7/14/2016) It's here.

---

Originally posted by 130s on ROS Answers with karma: 10937 on 2016-06-08

Post score: 1

---

Original comments

Comment by gvdhoorn on 2016-06-13:
Yes, I'd be interested in knowing about this as well. I seem to remember @dirk thomas giving a rationale once (mailing list, here on Answers, ..), but I can't find it anywhere anymore.

Answer 1

The end behavior of build.ros.org was setup to follow as closely as possible what previously existed on the previous generation of the buildfarm.

The default to off is because they take non-trivial resources, and also send emails to committers. If someone spun up their own buildfarm, and just turned it on we didn't want everyone in the ROS ecosystem getting devel job emails from multiple buildfarms. So you need to turn it on when you setup your buildfarm.

For the pull-request builds, it requires action on the users part to turn on the hooks on github. And we also only have support for github. As such we would end up with a lot of permission errors if the @ros-pull-request-builder is not granted access, or it is any other git host. As we specifically do not require github for hosting.

---

Originally posted by tfoote with karma: 58457 on 2016-08-23

This answer was ACCEPTED on the original site

Post score: 0