| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
@tfoote
Following up from some comments during the last TSC meeting and this ancient thread, I’d like to check what tasks need to be done to get Debian Buster as a Tier 2 supported platform for ROS 2 Eloquent.
In particular what infrastructure do we need to set up and what do we need to provide to where for the binary packages to be made available?
This would be a good starting point @gbiggs.
I am working with @gbiggs for Tier 2 support.
I installed and ran ROS 2 Eloquent with Buster.
So next , I want to create a CI for Buster.
I think the following two are important for Tier 2 support, is it correct?
First of all, we plan to build and verify Master, Agent (added Debian), and Repo on private servers.
What should we do as the next step?
And what support should we do for CI failures?
What are your thoughts on this @nuclearsandwich? I know back in July you worked on Tier 2 support for armhf.
I was discussing this with @tfoote just now and we think that for the moment it would be okay if you added a Debian Buster build to ci.ros2.org via pull requests to GitHub - ros2/ci: ROS 2 CI Infrastructure as the shortest path to shareable results. To make developing that PR easier it might make sense to set up a local CI clone which would require at least two virtual machines, one for the master and one for the agent.
Linux builds on ci.ros2.org and ros_buildfarm are run inside Docker containers, so it is not necessary for either setup to have agents running Debian natively and I’d expect there to be some problems doing so since the configuration management for buildfarm_deployment and the instructions available for setting up ci.ros2.org infrastructure all assume Ubuntu 16.04.
@miker256 this article uses ROS from Buster repositories and is not going to be much use when supporting mainline ROS 2 development on Debian Buster since they’ll need tool versions from our repositories not Debian’s.
armhf required additional agents because none of our existing agents, which are amd64 and arm64, had support for the armhf instruction set. Adding support for Debian builds is a matter of configuration, either forking GitHub - ros2/ci: ROS 2 CI Infrastructure or adding a config file to GitHub - ros2/ros_buildfarm_config (this route also has binary release requirements, see Python3.5 support lost in Dashing release · Issue #735 · ros2/ros2 · GitHub).
Thanks for the response.
We will start building the Debian agent with Docker and incorporating it into Buildfarm.
I have an additional question.
If PR is merged, Debian will be added to ros2/ci. What’s the difference between Tier1 and Tier2?
Thanks for the detailed response, @nuclearsandwich.
Support tiers are defined in REP-2000.
ros2/ci has many different job types
Right now support tiers describe what may block a release, automated testing frequency requirements, and, on platforms where per-package binaries are available, what type of binaries we provide. In the past it’s been easier to add additional nightly jobs for tier 2 platforms rather than create a separate periodic job type. But only the Tier 1 platforms are triggered as part of a pull request review process and even with nightly jobs running that does not mean that our on-call build farmer is required to respond to issues on other platforms. Once the jobs are running on CI we’ll expect that the community members who want to support Debian will do the work of checking the periodic jobs and getting them on par with the other platforms.
I understand the difference. Thank you for the detailed explanation @nuclearsandwich.
@nuclearsandwich
We prepared the buildfarm using virtual machines, and create a job using https://github.com/ros2/ci, but I have one question.
The sub-module https://github.com/osrf/rticonnextdds-src/ included in https://github.com/ros2/ci seems to be private.
Now, comment out the part of the Dockerfile that adds the license and run the job with the option not to use Connext. Do we have to contract and prepare our own RTI Connext DDS license?
The logic in ros2/ci has two options to use Connext:
osrf/rticonnextdds-src repo is for). Since this repo is private you would need to talk to RTI if you want access to their sources in a similar way.Sticking to just the first option is probably fine for you.
Thank you for your response. @dirk-thomas
I will try the first option in my local environment.
@dirk-thomas
We modified the Dockerfile and finished testing with jenkins. The build was successful, but some test fail. The test summary is as follows.
Summary: 268 packages finished [1h 4min 57s]
6 packages failed: ros2action ros2component ros2doctor ros2node ros2service ros2topic
11 packages had stderr output: ament_lint osrf_pycommon pendulum_control rcl rclcpp rclpy rcutils rqt rviz_default_plugins rviz_rendering test_rclcpp
9 packages had test failures: rclcpp ros2interface ros2msg ros2param ros2pkg ros2srv rviz_default_plugins rviz_rendering sros2
Should we fix all these errors before sending PR to ros2/ci?
Please try another build with the latest state. I would assume most of these errors should have been resolved by now.
Please feel free to create the PR whenever you are ready. Once that is the case we will kick off some jobs anyway to check their status.
Thank you for answering. @dirk-thomas
When I tried from the latest commit, test results have been improved.
There are still some errors, but it seems to be caused by the version difference of apt package.
I also created a PR.
https://github.com/ros2/ci/pull/355
Please let me know if there is any additional work.