GitHub Actions for ROS, and ROS 2 CI (beta)

Hi all,
GitHub launched last year GitHub actions, a new feature to build CI/CD pipelines from any GitHub repository. This service is similar to Travis, but provides the ability to implement, and release pipeline “steps” (actions) directly to a marketplace.

The ROS tooling working group has been developing three actions to enable GitHub users to build ROS CI/CD pipelines:

It is used by a few packages, such as rosbag2, or system_metrics_collector. See the actions tab of those repositories to see the jobs we run.

Runs happen on pull requests, and master is re-tested every two hours.

Supported Platforms

The GitHub actions aim for strict REP-3 and REP-2000 compliance. Actions support all non-EOL ROS distributions, on all Tier-1 platforms. In particular, this action supports macOS, and Microsoft Windows (ROS 2 only).

For macOS, and Microsoft Windows, the OS version specified in the REPs may
not be available as a GitHub Hosted runners.
In this case, GitHub actions will use the closest available worker
environment. Users requiring exact REP compliance should run the action on a self-hosted
runner
.

Example of GitHub Pipelines

Those three actions can be customized to build a variety of pipelines. This is made easier by the various GitHub actions already released on the marketplace.

Code quality, Stability, Known Issues

The action code is beta quality. It will probably work out of the box for simple use cases, but you may encounter bugs, in particular Windows and OS X support is still fragile.

All actions include tests to validate the CI infrastructure.

The biggest issue we are dealing with at the moment, is flakyness when setting up workers (APT repo timeout, etc.). We will be working on decreasing flakyness during Q1’20.

Future Development

We plan to continue improving the actions in the future, all new developments will take place through the ROS Tooling working group.

Please let the WG if you use the actions, all feedback is welcome! Thank you! :tada:

28 Likes

Great work! I’ll definitely be taking a look into this. I have a couple of smaller projects that have gained enough maturity to release and I’ll give this work a whirl and post in the appropriate repos / here with any feedback. I know basically nothing about the GitHub actions right now, so its a great test for a novice user following instructions for the first time :wink:

Any plans for adding something to use these tools to automatically deploy with bloom? If I create a new GitHub release, automatically run bloom over it with some configuration file that fills out the prompts, and files the rosdistro PR?

If this work could automate CI, merges into master hook into dockerhub, and bloom, that would completely replace my needs for CircleCI / Travis.

2 Likes

We will be moving the entirety of Autoware.AI and Autoware.Auto to GitHub in around about May, and I think we will try to use this work to replace our GitLab CI setup. Thanks for providing this!

3 Likes

That would be a nice addition, and something around those lines is already our backlog. I don’t we would have the bandwidth to do that soon (it would probably require creating another action). GitHub action certainly can trigger particular workflows on tags, so there is nothing preventing this from being implemented.

For ros-tooling/cross_compile, we are doing something close to what you’re suggesting: when new code is pushed, we push a new Python package to PyPI (pip) test repository.

This looks great, I’ll be sure to try it when I’m next playing around with a standalone package - even though industrial_ci is a great wrapper, Travis itself has started to get flaky.

If you’re thinking of doing https://github.com/ros-tooling/action-ros-ci/issues/7 to generate debs out of github actions (and hence outside of the standard rosdistro/ros_buildfarm flow), you may find it best to avoid bloom and separate release repositories entirely. It seems that bloom is particularly useful for:

  • generating cross platform packaging artifacts
  • applying (and re-applying) patches to sources outside of your control

We’ve already been using this for a while in the nodl library, very nice work @Thomas_Moulard, thank you!

Is there a better way to generate the debian/ dir from a ROS package than bloom-generate?

1 Like

Nice work! Love to see more adoption of GitHub actions for ROS CI. For Windows side, I am starting to beta-test it and hope my experience can help here. :slight_smile:

2 Likes

Well that’s embarassing, I didn’t know about the bloom subcommands, very handy!

If we’re talking about a hypothetical github action that takes a respository and generates a deb (and maybe uploads it to an apt repo?), bloom-generate still wouldn’t be very useful. It ties you to an upstream rosdistro and ros_buildfarm (rosdep, distro cache, ros-distro-* dependencies) artifacts, so it wouldn’t quite let you generate ‘standalone’ packages. But maybe that’s not the point and I’m missing it entirely.

I’ve procrastinated on getting CI/CD set up for the repositories I maintain. Looks like now I have justification :wink:

Nice work, looking forward to checking it out.

1 Like

Eclipse Cyclone DDS C++ repo uses pipelines, works great! Pipelines is free unlimited CI/CD minutes for all open source projects on github