[IJKL] Enable test_pull_requests for rqt plugin repos that are recently split from meta repos.

[130s]

CI choice should be up to the maintainer of each repository but since these packages are split from unified repos, it makes to me to recommend the default, generic CI option (hopefully most of maintainers will appreciate if CI is already setup).

Jade? Sorry I slacked off there :/

[dirk-thomas]

Since these repositories do not contain any tests and consist of Python code which isn't being compiled I don't see why those should have PR jobs?

[mikaelarguedas]

agreed I think a handfull of repos could benefit from it (like https://github.com/ros-visualization/rqt_rviz) but definitely not all of them. I think that leaving it to the maintainers is the best option

[130s]

What's the downside of having the default CI in the beginning of new repos do you guys think? If maintainers don't like the buildfarm CI that's :/ but then they can always disable it.

Python package or packages without tests can still benefit from CI; check dependency, grammars etc. Green light on PR is one good sign for merging than not having any validation mechanism.

I don't have a very strong opinion about this PR, but then we should remind the new maintainers about adding CI; understandably maintainers often forget to add CI. I've opened dozens of PRs to add CI config.

[dirk-thomas]

If maintainers don't care for having CI tests we shouldn't generate them just because we can. They are not "free" - each job costs resources on the master and each build cost resources on the nodes.

[130s]

Fair enough. Now I've updated the commit to add test_pull_requests for the only packages that I maintain.contain or rqt_image_view that contains C++ code and you @dirk-thomas maintains.

[dirk-thomas]

@130s Please also do the same for Jade.

[130s]

Yes, done.