Hi all, your friendly neighborhood navigator here.
I wanted to let you know that in Nav2-land we’ve started to automated elements of our process and take into account some user feedback over the past year or so. So I’d like to mention a few key changes in case you run into them (or what to use them) as you’re contributing to Nav2.
PR Bots Starting last week, I’ve enabled a handful of bots to help me in my day-to-day PR reviewing processes using the tool Mergify. These are giving me some nice helper capabilities to remove alot of the boilerplate comments / topics I often need to address with contributors. In particular, if you see a mergify bot ask you to do something, please do it (except if we’ve discussed otherwise).
You may be asked to do one of the following:
- Resolve a merge conflict before I review your PR (again)
- Target the
mainbranch for your contribution, not a specific distribution. I have bots in place to make it easier for me to backport PRs to other distributions if appropriate. - If your PR build fails, you will be asked to fix it before I review your PR (again)
- Properly fill in the PR templates, especially as it relates to checklists and key information needed for me to keep our code and documentation quality high
More may be added into the future, but these are some key points I frequently have to handle manually that are now largely automated.
CircleCI It has come to my attention that some users have some issues logging into CircleCI. For the first time you do so, it asks for some permissions which I’d also argue is a bit aggressive. Most users have no issues or express issues in this, but occasionally someone doesn’t want to give them that permission and are then unable to fix up their CI with test / build failures.
Starting today, all new PRs have a GitHub checks hook with CircleCI so that you may see the status and results of CI jobs without having to log into Circle, using the GitHub UI (example here). If you need more information (like logs), you may need to login, but this should get you the important high level information about what tests / packages failed.
Containers Due to some changes in DockerHub, we’ve changed over to using GitHub’s container registry. I have to admit, its not the most ideal setup. The URLs are a bit confusing and its quite buried in the GitHub UI. GitHub decided to merge the “packages” and the “containers” concept into the same bucket, so when you see packages on Nav2 / Moveit2 / etc, that’s where the Docker container information lies (e.g. here).
These containers will be used from now on, rather than DockerHub, for managing main CI containers and software distribution. We already have about 6k downloads, so clearly some of you have been made aware of this already. Each container is marked with a hash on the date it was built and should be building within roughly a day of a ROS 2 container update. The main tag will be the current status of the main of Nav2. At the moment, we do not release Docker containers for released distributions, but if folks would like that, we can arrange it easily. Right now, this is triggered through a GitHub Action (the only such action in Nav2 for now).
I hope that gives you a good understanding of some of the process / bots / container updates we’ve been making over the last couple of weeks. Please comment with any questions / concerns / comments and we will make sure to answer or address them.
Happy responding-to-bot-ing,
Steve