Add ament_cmake into build system

[maximosipov]

New Feature

In order to transition to ROS2 it is necessary to convert build system to ament_cmake and update packages according to Migration Guide.

There are several build processes in Autoware to update and test:

• Travis CI is obsolete and replaced by Gitlab CI (will not be updated, need to eliminate .travis.yml and update docs)
• Gitlab CI is the current choice (will be updated based on https://github.com/esteve/Autoware/tree/feature/use_ament_vector_map, requires linking autoware repo into Gitlab from Github and updating docs)
• Native Docker build (will be updated on the top of crossbuild dockerhub  autoware#1982, however currently uses catkin due to Add missing install target to all packages that produce libraries or executables #491)
• Cross Docker builds (will be updated on the top of crossbuild dockerhub  autoware#1982, may be affected by Add missing install target to all packages that produce libraries or executables #491)
• Native host build (will be updated)

In addition, currently using ament_cmake requires using ament_ from ROS2 distribution which is not a recommended practice, see Discourse Topic, however it demonstrated to work.

Started work on https://github.com/maximosipov/autoware/tree/feature/ament_ci_and_docker

[gbiggs]

Is using Gitlab CI for a Github project a good idea? What benefits does Gitlab CI give us over Travis CI or another agnostic tool like CircleCI?

[maximosipov]

@gbiggs Gitlab CI was introduced by autowarefoundation/autoware#1563, I think it make sense to use just one framework, whatever the choice is, and the current support for Gitlab CI is definitely more flexible.

[sgermanserrano]

@gbiggs Gitlab Ci was introduced as a replacement for Travis CI to overcome the problems that Travis CI had to run the unit tests. Also as a way to bring .Auto and .AI closer.

Nevertheless each tool has its own benefits and defects, Gitlab CI cannot pick up PRs from branches in forks of Autoware, hence only the Travis CI checks appear in the PR. On the positive it is free for Open-Source projects and the time limit can be manually changed so that Autoware builds do not time out.

[esteve]

@gbiggs like @sgermanserrano said, we wanted to bring the two projects closer and as a first step we decided to use GitLab, also we were having lots of issues with Travis, so we needed to switch to something else anyway.

Like CircleCI, GitLab runners can be hosted on premises, however and although we'll initially only support Linux, GitLab supports macOS and Windows as well (e.g. @maximosipov reported a bug in Authoware.Auto when building on macOS, so we want to support that too)

I personally like Azure Pipelines a lot, but in order to keep the infrastructure consolidated, we went with GitLab.

[gbiggs]

Yeah, I'm a fan of Azure Pipelines, too.

Thanks for the explanations! No one's been able to tell me for four weeks. 😆

[esteve]

@gbiggs sorry about that, we should have a document explaining this sort of decisions. Moreover, we'll also have to look into consolidating the CI scripts as well, right now we use https://github.com/ros-industrial/industrial_ci, and custom scripts in GitLab and Travis. industrial_ci is a great solution, however it doesn't support colcon nor ROS2 yet, so we'll have to either contribute it upstream or keep using our scripts. I'd rather push upstream as much as possible, instead maintaining our own stuff, but I don't have an estimate of how much work it'd require to support colcon in industrial_ci.

[130s]

Thanks for the mention for industrial_ci (I'm one of the maintainers). ROS2/Colcon support is discussed in ros-industrial/industrial_ci#333 without specific goal, probably because of the lack of concrete drive. If you could voice up there that could help someone to pick up the pieces :)

[gbiggs]

I'm all in favour of pushing anything we can upstream. It's good for the community, and it means less for us to maintain all by ourselves.

[esteve]

@130s thanks for dropping by. I followed that ticket a bit, and the consensus seemed that industrial_ci would be rewritten in Python first before adding support for colcon. Anyway, I've responded there to get the ball rolling.