update travis.yml #6

k-okada · 2019-04-03T02:05:34Z

Created travis.yml using

Please activate GitHub - TravisCI integration to enable this test
https://github.com/apps/travis-ci

k-okada · 2019-04-03T02:11:12Z

@d-nakamichi can we enable TravsiCI ?

Go through the instructution here
https://qiita.com/hoshimado/items/4090d8e64beb8a7f95e1#travis-ci%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E4%BD%9C%E6%88%90%E3%81%A8%E5%AF%BE%E8%B1%A1%E3%81%AEgithub%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%82%92%E7%B4%90%E4%BB%98%E3%81%91
Until “これで、Travis CI側の設定は完了。”

d-nakamichi · 2019-04-03T06:20:39Z

Thanks for your help!
Now I activated GitHub - TravisCI integration.

gavanderhoorn · 2019-04-03T06:24:55Z

@k-okada: did you have any particular reason not to use industrial_ci? It's not a panacea, but leads to very readable and simple .travis.yml files (see this one as an example).

Edit: test build with industrial_ci: test build (takes approx 10-ish minutes per build config matrix row).

Tries to load xacro as parameter.

Tries to load xacros as parameters.

Avoid setting link directories.

'khi_robot_msgs' is already a build_depend and is another package, so build ordering will already take the dependencies into account.

The main library is not exported (by catkin_package(..)), so the headers also don't need to be installed. This also resolves an installation issue: the install(..) statement expects a sub dir called 'khi_robot_control' in the 'include' directory, but that doesn't exist.

Make catkin_lint happ(ier).

gavanderhoorn · 2019-04-03T08:55:39Z

@k-okada: it appears you merged an older version of master...gavanderhoorn:pkging_updates.

k-okada · 2019-04-03T09:06:06Z

@gavanderhoorn yes, i know. I just want travis to answer

@k-okada: could you verify this also works for you?

question.

Please wait at most 16 hours, I will finalize this PR and ready to merge and release working version so that we can put khi_robot to the this week's sync.

gavanderhoorn · 2019-04-03T09:07:30Z

Your proposed travis config is not working because it also includes an Indigo build. The IKFast plugins cannot build under Indigo.

@gavanderhoorn yes, i know. I just want travis to answer

@k-okada: could you verify this also works for you?

question.

My question was specifically about gavanderhoorn@6641def. Your add_travis branch does not contain that commit.

I'm also unsure whether Travis can catch linking issues with dynamic libraries, as there are currently no tests, so no binaries are ever run.

I've run a quick Travis test here with an up-to-date master...gavanderhoorn:pkging_updates and that seems to succeed.

@k-okada

Based on suggestion from @k-okada. Not sure whether this is an actual proper solution, or just a work-around. Systems with stricter ld library path security might not like this.

d-nakamichi · 2019-04-03T23:48:32Z

@k-okada @gavanderhoorn

industrial_ci
prerelease.sh

Which is better?
For testing just build/install package, industrial_ci seems better because it can select prerelease or not.
Run ROS Prerelease Test

k-okada · 2019-04-04T00:25:01Z

@d-nakamichi @matsui-hiro @gavanderhoorn Although 2c0a73e did not failed as I expected, but I think this PR is ready to merge and release.

==

@k-okada: did you have any particular reason not to use industrial_ci?

ros_buildfarm is less likely to loose maintainer, If ros_buildfarm is orphaned and we have no alternatives, that’s mean the end of ROS. For example, every time we have new ROS distro or new Ubuntu version, we can assume it is OSRF jobs to update the ros_buildfirm to support them. But as for industrial_ci, someone have to do that. (In my opinion, if ROS-I have the resource to maintain industrial_ci that effort should goes to maintain image_pipeline, rqt, ros-drivers,,, and so on...)
My understanding of industrial_ci is customizable, (At least originally, because that is originally coms from our http://github.com/jsk-ros-pkg/jsk_travis ) So when the source tree did not pass the travis we have opetion to customize the CI parts, for example skip some package, run extra scripts and so on...., and it is good compromise between stability vs development speed, for research labs. But for industrial application, stability is much important. So if we do not pass the travis, we should fix source tree. (So ideally, we should run build script, in addition to prerelease, because our intrest is if the source tree is able to run on the buildfirm.)

d-nakamichi · 2019-04-04T04:46:38Z

OK. khi_robot uses prerelease at the begging.
I'll accept this PR.
Thanks! @k-okada @gavanderhoorn

gavanderhoorn · 2019-04-04T06:11:15Z

@d-nakamichi @k-okada: this PR included ~~a lot of~~ mostly my commits. I would have appreciated it if #5 could have been merged instead. Now changes to the packaging and build setup are merged from a PR that is unrelated (ie: one that "update[s] travis.yml"), which is not good maintainership practice.

~~This cannot be fixed now any more, but in the future please do not do this with my pull requests.~~

My apologies, the github UI confused me. It seems both PRs were merged.

gavanderhoorn · 2019-04-04T06:17:47Z

@k-okada: did you have any particular reason not to use industrial_ci?

1. ros_buildfarm is less likely to loose maintainer, If ros_buildfarm is orphaned and we have no alternatives, that’s mean the end of ROS. For example, every time we have new ROS distro or new Ubuntu version, we can assume it is OSRF jobs to update the ros_buildfirm to support them. But as for industrial_ci, someone have to do that.

I don't really follow your argument here.

Are you worried about whether industrial_ci will be maintained in the future?

(In my opinion, if ROS-I have the resource to maintain industrial_ci that effort should goes to maintain image_pipeline, rqt, ros-drivers,,, and so on...)

I guess we don't agree here: ROS-Industrial is not responsible for maintaining all sorts of packages. Resources are limited everywhere, so we have to make choices.

industrial_ci fulfils a direct need of ROS-Industrial members, so it makes sense to spend effort there.

2. My understanding of industrial_ci is customizable, (At least originally, because that is originally coms from our [http://github.com/jsk-ros-pkg/jsk_travis](https://github.com/jsk-ros-pkg/jsk_travis) ) So when the source tree did not pass the travis we have opetion to customize the CI parts, for example skip some package, run extra scripts and so on...., and it is good compromise between stability vs development speed, for research labs. But for industrial application, stability is much important. So if we do not pass the travis, we should fix source tree.  (So ideally, we should run build script, in addition to prerelease, because our intrest is if the source tree is able to run on the buildfirm.)

re: customizable -> for research labs: I don't fully understand your reasoning here. industrial_ci supports running prereleases as well as many other things. Changing .travis.yml for industrial_ci has to go through the same process (ie: a pull request that should be reviewed) as with the current setup.

What you write are maintenance policy / development process concerns. All software is customisable, and I doubt industrial_ci is any more customisable than the current .travis.yml. In either case: no maintainer can just go in and chance CI configuration, unless the repository has been badly configured.

Seems to have been remove in Kawasaki-Robotics#6.

k-okada · 2019-04-04T07:34:50Z

@gavanderhoorn Then, what is the reason for having industrial_ci? in addition to the prerelease.py ?

gavanderhoorn · 2019-04-04T08:10:06Z

@gavanderhoorn Then, what is the reason for having industrial_ci? in addition to the prerelease.py ?

I believe it would a bit too much to discuss this in a comment.

I'd refer you to the readme and the rest of the documentation.

For me personally, readability of the travis configuration is a big plus. Compare: this with this (if pinning of industrial_ci is a concern, specify a version here).

Please note that I don't feel strongly about this. If you're happy with what you're using right now then please keep using that :)

k-okada · 2019-04-04T12:22:12Z

For me personally, readability of the travis configuration is a big plus.

Compare: this with this (if pinning of industrial_ci is a concern, specify a version here). If that is the problem, prepare one script and write `curl -sL ttps:// raw.github.com/ros-industrial/industrial_ci/master/run_prerelease.sh | bash` in travis.yml

Please note that I don't feel strongly about this.

Yeah, I know.

Seems to have been remove in #6.

d-nakamichi requested review from d-nakamichi and matsui-hiro April 3, 2019 06:12

d-nakamichi self-assigned this Apr 3, 2019

d-nakamichi approved these changes Apr 3, 2019

View reviewed changes

matsui-hiro approved these changes Apr 3, 2019

View reviewed changes

k-okada closed this Apr 3, 2019

k-okada reopened this Apr 3, 2019

update travis.yml

2263c3a

k-okada force-pushed the add_travis branch from fba05cc to 2263c3a Compare April 3, 2019 08:41

gavanderhoorn and others added 16 commits April 3, 2019 08:51

rs_desc: add missing install targets.

102c33f

duaro_desc: add missing install targets.

6c5eca0

rs_gazebo: add missing install targets.

9162797

duaro_gazebo: add missing install targets.

f488630

description: pkgs do not run depend on urdf.

a640687

duaro_desc: add roslaunch testing.

428cedd

Tries to load xacro as parameter.

rs_desc: add roslaunch testing.

0351a14

Tries to load xacros as parameters.

robot_control: use imported target for KRNX binary blob.

33d9ab5

Avoid setting link directories.

robot_control: warn user if CPU arch could not be detected.

8a05da8

robot_control: remove redundant dep declaration.

233d066

'khi_robot_msgs' is already a build_depend and is another package, so build ordering will already take the dependencies into account.

robot_control: sort components alphabetically.

7ca1dfc

Make catkin_lint happ(ier).

robot_control: fix realtime_tools unconfigured build dep.

d1bf9da

robot_control: sort source files for robot_client target.

4a3d157

Make catkin_lint happ(ier).

moveit_cfgs: install scripts dir.

19792a2

rs080n_moveit_config does not have script directory

a3a1596

gavanderhoorn mentioned this pull request Apr 3, 2019

descriptions: improve composability and use of xacro features #8

Merged

set indigo as allow_failures

c1546a9

k-okada force-pushed the add_travis branch from c3463db to 2c0a73e Compare April 3, 2019 22:35

k-okada and others added 2 commits April 3, 2019 22:39

add test for khi_robot_control/main and libkrnx

2c0a73e

robot_control: work-around for KRNX lib blob linking issues.

62aa1a7

Based on suggestion from @k-okada. Not sure whether this is an actual proper solution, or just a work-around. Systems with stricter ld library path security might not like this.

Merge branch 'master' into add_travis

78085f9

d-nakamichi merged commit e2366fe into Kawasaki-Robotics:master Apr 4, 2019

gavanderhoorn added a commit to gavanderhoorn/khi_robot that referenced this pull request Apr 4, 2019

robot_control: fix msg deps of main.

786004d

Seems to have been remove in Kawasaki-Robotics#6.

gavanderhoorn mentioned this pull request Apr 4, 2019

robot_control: fix msg deps of main. #9

Merged

k-okada deleted the add_travis branch April 4, 2019 07:32

d-nakamichi pushed a commit that referenced this pull request Apr 5, 2019

robot_control: fix msg deps of main. (#9)

018d677

Seems to have been remove in #6.

gavanderhoorn mentioned this pull request Apr 12, 2019

Add test_depend #11

Merged

sktometometo mentioned this pull request Sep 29, 2020

Bugfix for noetic release #44

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

update travis.yml #6

update travis.yml #6

k-okada commented Apr 3, 2019

k-okada commented Apr 3, 2019

d-nakamichi commented Apr 3, 2019

gavanderhoorn commented Apr 3, 2019 •

edited

gavanderhoorn commented Apr 3, 2019

k-okada commented Apr 3, 2019

gavanderhoorn commented Apr 3, 2019 •

edited

d-nakamichi commented Apr 3, 2019

k-okada commented Apr 4, 2019 •

edited

d-nakamichi commented Apr 4, 2019

gavanderhoorn commented Apr 4, 2019 •

edited

gavanderhoorn commented Apr 4, 2019

k-okada commented Apr 4, 2019

gavanderhoorn commented Apr 4, 2019

k-okada commented Apr 4, 2019 via email

update travis.yml #6

update travis.yml #6

Conversation

k-okada commented Apr 3, 2019

k-okada commented Apr 3, 2019

d-nakamichi commented Apr 3, 2019

gavanderhoorn commented Apr 3, 2019 • edited

gavanderhoorn commented Apr 3, 2019

k-okada commented Apr 3, 2019

gavanderhoorn commented Apr 3, 2019 • edited

d-nakamichi commented Apr 3, 2019

k-okada commented Apr 4, 2019 • edited

d-nakamichi commented Apr 4, 2019

gavanderhoorn commented Apr 4, 2019 • edited

gavanderhoorn commented Apr 4, 2019

k-okada commented Apr 4, 2019

gavanderhoorn commented Apr 4, 2019

k-okada commented Apr 4, 2019 via email

gavanderhoorn commented Apr 3, 2019 •

edited

gavanderhoorn commented Apr 3, 2019 •

edited

k-okada commented Apr 4, 2019 •

edited

gavanderhoorn commented Apr 4, 2019 •

edited