Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Travis: switch to xenial build environment and add clang and C++11 jobs #195

Open
wants to merge 27 commits into
base: master
Choose a base branch
from

Conversation

meyerj
Copy link
Member

@meyerj meyerj commented Jan 5, 2017

Example build: https://travis-ci.org/orocos-toolchain/rtt/builds/189295270

Travis supports containerized builds since 2 years, which improve build times. With the apt add-on it is also possible to install system dependencies without the need for sudo. (see #195 (comment)).

I also added a build matrix to test clang and gcc builds with and without c++11 enabled. We might also include Mac OS X here.

We are already running integration tests for the toolchain for the orocos_toolchain repository, but without unit tests: orocos-toolchain/orocos_toolchain#15 (only log4cpp, rtt and ocl)

@ahoarau
Copy link
Contributor

ahoarau commented Jan 6, 2017

Different gcc and clang version could also be useful (especially gcc5+ and clang 3.8+)

@snrkiwi
Copy link
Contributor

snrkiwi commented Jan 7, 2017

litmus

@snrkiwi
Copy link
Contributor

snrkiwi commented Jan 7, 2017

LGTM .... grrr, auto-correct!

@meyerj
Copy link
Member Author

meyerj commented Jan 11, 2017

Different gcc and clang version could also be useful (especially gcc5+ and clang 3.8+)

Done. Both gcc 5.4 builds currently fail consistently because of a check error in dev_test.

The method_test occasionally stalls for some jobs and Travis aborts after 10 minutes. Could be related to the containerized build environment.

@ahoarau
Copy link
Contributor

ahoarau commented Jan 11, 2017

Excellent ! That could be useful for the xenial (gcc5 default ) / kinetic release (?)

All other branches require a pull request to be created to trigger Travis.
This way we avoid duplicate builds.

Signed-off-by: Johannes Meyer <[email protected]>
@meyerj
Copy link
Member Author

meyerj commented Apr 16, 2019

Unfortunately the containerized build infrastructure has been deprecated again in the meantime. We can still apply most of the changes in this PR and switch to xenial (#279), which is now supported by the fully virtualized infrastructure.

@meyerj meyerj changed the title Travis: switch to containerized build environment and add clang and C++11 jobs Travis: switch to xenial build environment and add clang and C++11 jobs Apr 17, 2019
…referenced element as a temporary)

Signed-off-by: Francisco Almeida <[email protected]>
CORBA::Exception does not extend std::exception and is usually unknown to the Boost Test Framework.
Register an exception translator to show the name of the exception and then rethrow a copy
(https://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost/execution_monitor.html#idp57106832-bb).

Signed-off-by: Johannes Meyer <[email protected]>
@meyerj
Copy link
Member Author

meyerj commented Apr 18, 2019

We could try to enable ccache for Travis builds to eventually reduce the build times. If I understood correctly there is one cache per branch and pull request builds use the cache of the default branch.

Unfortunately some unit tests are still unreliable on Travis in a virtualized environment because they depend on more or less accurate timing or check timeouts. Those test cases could be disabled for CI by checking the CI environment variable, or the expectations must be relaxed.

Previous related issues:

The build matrix with 6 or more jobs makes it more likely that this will happen.

@ahoarau
Copy link
Contributor

ahoarau commented Apr 18, 2019

@meyerj
Copy link
Member Author

meyerj commented Apr 18, 2019

What about using https://github.com/ros-industrial/industrial_ci ?

What would be the added value of industrial_ci? As far as I know it compiles the package and runs the unit test in a docker container that has a proper ROS environment. Being able to test on newer platforms, like Ubuntu Bionic, with newer Boost versions would definitely be a plus. On the other hand RTT is not a ROS package (e.g. make run_tests would not work) and would not need many of the ROS tools. I also do not see how running in docker helps with fixing flaky unit tests that depend on timing.

Is there another advantage of industrial_ci that I am not aware of?

I suggest to leave that for a later PR. One of the things we wanted to try here is adding macOS to the build matrix, which would not be possible with docker, I guess.

One C++03 build is enough to test pre-C++11 support.
We will also enable ccache to check if it breaks anything.
@ahoarau
Copy link
Contributor

ahoarau commented Apr 18, 2019

What would be the added value of industrial_ci?

Just very simple to setup in all the "standard" environnements (aka distribs), from my ROS user point of view of course.
I have no idea how many people are using rtt in a non-ros env.
True that having a minimal build is nice, as long as it covers many compilers version/boost version combinations, usually provided by main distribs.

…NO_EMIT_CORBA_IOR is set

This is expected to fix a failure on Travis CI if no nameserver is available, especially on macOS.

Signed-off-by: Johannes Meyer <[email protected]>
@meyerj meyerj force-pushed the travis/containerized-build branch 4 times, most recently from 700dc2c to 07839e4 Compare May 7, 2019 09:59
@meyerj meyerj force-pushed the travis/containerized-build branch from 07839e4 to 04c0d90 Compare May 7, 2019 11:13
@meyerj
Copy link
Member Author

meyerj commented May 8, 2019

Turns out the the corba-ipc-test fails on macOS because the corba-ipc-server process running in the background "forgets" about the registered types. As a result the connection attempts made by the corba-ipc-test fail with

0.053 [ Debug  ][Logger] Scanning file /Users/travis/build/orocos-toolchain/rtt/build/install/lib/orocos/macosx/./types/librtt-typekit-macosx.dylib ...Found library librtt-typekit-macosx.dylib
0.022 [ Info   ][TypekitRepository::Import] Loading Typekit rtt-types.
0.022 [ Debug  ][TypekitRepository::Import] Registered Type 'int' to the Orocos Type System.
0.022 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for int
0.022 [ Debug  ][TypekitRepository::Import] Registered Type 'uint' to the Orocos Type System.
0.022 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for uint
0.023 [ Debug  ][TypekitRepository::Import] Registered Type 'llong' to the Orocos Type System.
0.023 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for llong
0.023 [ Debug  ][TypekitRepository::Import] Registered Type 'ullong' to the Orocos Type System.
0.023 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for ullong
0.023 [ Debug  ][TypekitRepository::Import] Registered Type 'double' to the Orocos Type System.
0.023 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for double
0.023 [ Debug  ][TypekitRepository::Import] Registered Type 'float' to the Orocos Type System.
0.023 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for float
0.023 [ Debug  ][TypekitRepository::Import] Registered Type 'char' to the Orocos Type System.
0.024 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for char
0.024 [ Debug  ][TypekitRepository::Import] Registered Type 'bool' to the Orocos Type System.
0.024 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for bool
0.024 [ Debug  ][TypekitRepository::Import] Registered Type 'void' to the Orocos Type System.
0.024 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for void
0.024 [ Debug  ][TypekitRepository::Import] Registered Type 'FlowStatus' to the Orocos Type System.
0.024 [ Debug  ][TypekitRepository::Import] Registered Type 'SendStatus' to the Orocos Type System.
0.024 [ Debug  ][TypekitRepository::Import] Registered Type 'PropertyBag' to the Orocos Type System.
0.024 [ Debug  ][TypekitRepository::Import] Registered Type 'ConnPolicy' to the Orocos Type System.
0.025 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for ConnPolicy
0.025 [ Debug  ][TypekitRepository::Import] Registered Type 'SendHandle' to the Orocos Type System.
0.025 [ Debug  ][TypekitRepository::Import] Registered Type 'TaskContext' to the Orocos Type System.
0.025 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for TaskContext
0.025 [ Debug  ][TypekitRepository::Import] Registered Type 'string' to the Orocos Type System.
0.025 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for string
0.026 [ Debug  ][TypekitRepository::Import] Registered Type 'array' to the Orocos Type System.
0.026 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for array
0.026 [ Debug  ][TypekitRepository::Import] Registered Type 'rt_string' to the Orocos Type System.
0.026 [ Info   ][TypekitRepository::Import] Registered new 'CORBA' transport for rt_string
0.058 [ Info   ][Logger] Loaded RTT TypeKit/Transport 'rtt-types' from 'rtt-typekit'
[...]
40.352 [ Warning][./corba-ipc-server::main()] The protocol with id 1 did not register a fall-back handler for unknown types!
40.352 [ Warning][./corba-ipc-server::main()]   triggered by: unknown_t which does not have a transport.
40.352 [ Debug  ][./corba-ipc-server::main()] Types known to the Orocos Type System.
40.352 [ Debug  ][./corba-ipc-server::main()] Transports known to the Orocos Type System.

(https://travis-ci.org/orocos-toolchain/rtt/jobs/529291825)

and ultimately both processes segfault.

I could reproduce this locally with a macOS 10.13 system. Surprisingly, if corba-ipc-server is started explicitly at the command line, all unit tests pass and the issue is gone. Only if it is launched via setup_corba or indirectly by make check the error is reproducible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants