We have at least one user of Navigation2 who is trying to run on MacOS. We haven’t had the resources to set up any CI or do any testing using MacOS.
So, I wanted to start the discussion of how we can support this in the most scalable way? I believe that the ROS build farm is building packages for Mac, but I’m not sure what testing is being done? Ideally, I’d like to leverage the build farm and not have to test every change on a Mac as well as Ubuntu.
If anyone has a solution for this that doesn’t involve a lot of manual setup and support, I’d love to hear it.
https://ci.ros2.org/ builds an archive every night and every release for macOS. Also, pull requests for any change to repositories in the ros2.repos file must pass on macOS as well. We have nightly jobs for macOS also. We treat macOS the same as Linux and Windows in that respect.
Currently we’re using an old version of macOS, but we have plans to update our farm’s machines in the near future.
I’m not sure what you’re asking for here, you mean depend on the build farm testing all of your dependencies or…?
If you’re going to support macOS you’ll either have to build every change against macOS (to prevent regressions) or build periodically (nightlys) and tackle regressions as they come up.
So If we want our code to build automatically on macOS in the build farm, we need to add our project to the ros2.repos file, is that correct? If so, we can submit a PR for that.
I believe there was talk of adding a new nightly job on ci.ros2.org that additionally tests the navigation stack, rather than adding it to the ros2.repos file, simply because our CI is already over 2 hours, so we’re trying to keep the list short until we have a more scalable solution (people are working on that for build.ros2.org).
@nuclearsandwich were we not talking about a navigation nightly at one point? Or am I imagining that?
As for packaging, I suppose we could try to add it to packaging but not CI, which is the case for the ros1 bridge for example. We also have some “supplemental” repos files which can be used in various ways when running jobs on ci.ros2.org, e.g.: https://github.com/ros2/ros2/blob/master/cyclonedds.repos
Our efforts have been on getting ros_buildfarm into a state where we can formalize that job and improve the CI experience on build.ros2.org rather than putting more onto ci.ros2.org. build.ros2.org doesn’t currently have support for non-Linux platforms.
I don’t think that we have the capacity to sustainably build community projects on ci.ros2.org as part of the omnibus packages ether via a broader repos file for packaging jobs or via an additional “layer” of builds on top of the current packaging jobs. This is due in part because of raw compute resources available and in part because managing that in the medium term sounds like it would eventually turn into re-implementing a bunch of what we have for rosdistro distribution management and if we’re going to do that I would rather focus on the long term goal of migrating all packaging from being .repos file based on ros2/ci to being rosdistro distribution.yaml-based via ros_buildfarm.
I don’t know your CI infrastructure very well (bare minimum TBH), so can someone tell me how I should proceed? If adding to the ros2.repos file is not the way to go, then what is?
I think @nuclearsandwich’s point is that we don’t have the resources to provide macOS jobs for everyone in the community, and I agree. We’re already running into cases where nightly jobs don’t finish until well into the workday for us.
I was thinking a single nightly job might be possible, but the reality is that we’re pretty much at capacity and don’t have plans to expand it.
On the other hand, build.ros2.org is meant for the whole community (and is where the nav nightly’s are run), but it currently doesn’t support anything but Linux. I think the plan is to eventually have Windows and even macOS for build.ros2.org, and in a way that can scale properly, but not in the near future.
I don’t have a solution for you other than to point you to resources that might help you setup your own macOS testing (travis, appveyor, or your own instance of our ci.ros2.org).
