Contribution idea for travis on ros-industrial github org

[130s]

I rather open a ticket here to ask opinions from smaller group for this.

In response to recruited contribution for travis in today's conference call, I'm willing to offer a help. Below I spread out my thoughts how to tackle this.

I found some (but not limited to) the repositories that seem to be missing travis config on their default branches.

• https://github.com/ros-industrial/industrial_core
• https://github.com/ros-industrial/motoman
• https://github.com/ros-industrial/fanuc
• https://github.com/ros-industrial/abb

I CAN open separate PRs for those repos to add travis config files. Thing with that is that the maintainers of each repository will be responsible for updating travis.yml when necessary.

Instead, because repositories under ros-industrial org are being coordinated, I think it makes more sense to aggregate travis config files at fewer or ideally at one common place, and repositories that need configs just depend on that common place if possible. This is possible using git functionality called submodule. In fact I just tested in my own org and worked fine with the following 2 repositories:

• This repo is where common travis conf is stored and maintained https://github.com/130s/common_travis/commits/master
• This is a "consumer" repo https://github.com/130s/user_common_travis

(JSK lab has been utilizing this mechanism for an year and half https://github.com/jsk-ros-pkg/jsk_travis and https://github.com/jsk-ros-pkg/jsk_common. Their configs are complicated due to their various requirements and thus not usable out-of-box, so my samples might be a good place to start.)

Of course whether or not each repository wants to be tested by travis depends on its policy. We can discuss if they want or not on their issue trackers.

If this sounds good, I can initiate the work. I appreciate your thoughts.

[gavanderhoorn]

@130s: this would be good to have across ros-i repositories.

However, personally I'm not really such a big fan of sub modules. And although there will be some duplication, I feel there isn't that much integration / coordination between the repositories that you list that would make it necessary to have a single travis config.

For the Fanuc repository fi, I sometimes try out some stuff that I wouldn't feel comfortable with to immediately have an effect on other repositories as well. An individual config would allow me to keep locality of changes high.

[gavanderhoorn]

Obviously this is just my opinion. Let's see some others.

[shaun-edwards]

@gavanderhoorn, @130s, would it be possible for some repos to use the common submodule and others a custom, repo specific, version? This way we could deploy travis across all of our repos (a good thing), but give maintainers the flexibility to customize their own travis builds if they wish?

[gavanderhoorn]

Sure. That should certainly be possible.

[shaun-edwards]

@130s, thoughts? I would be supportive of using git submodules for almost all repos and then letting specific maintainers like @gavanderhoorn opt out

[130s]

Sounds good; actually giving flexibility per repository is what I wanted to mention. I hope I can open a PR later today.
Do we want to create a new repository to store CI related files (like in my sample)? Or do we use an existing repository (eg. industrial_core) to store them?

I've been updating travis config files over 20+ repositories since Trusty got enabled, and although it's not a painful process at all to almost just copy-paste the same file for the repositories where no special requirements), it's just tedious and error-prone.

Meanwhile I understand there seem to be drawbacks for git submodules so if there's better option I can dig into that.

[shaun-edwards]

Does a git submodule result in "including" the entire repo? If this is the case, then I would prefer a dedicated repo...call it industrial_travis (I can create this repo for you ).

Updating 20+ repos sounds painful. I'd be the first to "forget" to update my repos. This does bring up a good point though? How do we handle ROS versions in git submodules?

[130s]

Does a git submodule result in "including" the entire repo? If this is the case, then I would prefer a dedicated repo...call it industrial_travis (I can create this repo for you ).

Yes it does include the entire repo, but only at "runtime of travis", so this shouldn't matter on our computers, on buildfarm or anywhere else than on travis. But I think separating a repo for CI configs is cleaner in many ways (so that especially developers don't need to see PRs about CI).
For the repo name, there may come other CI options in the near future so I suggest something generic (industrial_ci etc.), but industrial_travis sounds good too.

How do we handle ROS versions in git submodules?

Aside from submodules, I usually use so-called matrix where you can define sets of combination of environment variables. example
In this example by the way, we set not only ROS distros but also check DEB repos (public/shadow) and also check source build for designated packages.

[shaun-edwards]

@130s, I think you've addressed everything. Let's move forward.

I've created the repo for your efforts: https://github.com/ros-industrial/industrial_ci
Let's follow the PR/review model for changes.

[130s]

Thanks, I'm in some deadlines but will hopefully send PRs before TG break.
Just to make sure; is travis-ci enabled for industrial_ci and other repositories? If not, you can easily set it at https://travis-ci.org/profile/ros-industrial by sliding the buttons per repo.

[shaun-edwards]

@130s, I've enabled travis-ci. Please let me know if you need anything else..or if the travis-ci isn't done correctly.

[130s]

Thanks Shaun. I've opened ros-industrial/industrial_ci#1 and I see travis is successfully activated. I close this since we can move the discussion into relevant tickets and PRs but any meta comment about CI is welcomed.