ROS2 - Humble - Starter kit

Every project has to start from somewhere.

In this tutorial, we are going to see the minimal template to start any ROS 2 Humble projects with style and stability.

We're not just throwing code around, we will focus on how to keep your setup bulletproof.

For that goal we’re going to use GitHub Actions to automatically stress-test the Dockerfile and devcontainer.json files.

Basically, we’re making sure your dev environment is always "ready to roll" before you even type your first node!

Shopping list

• The Github of this tutorial: https://github.com/badprog/badprog-ros2-humble-starter-kit
• VSCode: https://code.visualstudio.com/

1. The Dockerfile

Think of your Dockerfile as the DNA of your project.

It’s based on ros:humble-ros-base, but we’ve customized it to make it comfortable:

• User power: No more root mess, we'll create a dedicated user (badprog) with sudo powers, because safety first, right?
• Clean workspace: We will prep /workspaces/ros2_ws with the right permissions so you’re not fighting "Access Denied" errors later.
• Auto-magic sourcing: We'll bake the ROS 2 setup right into the .bashrc file, so every time you open a terminal, it’s already tuned and ready to go.

2. The devcontainer.json file

The devcontainer.json file is like a VIP pass for your IDE.

It takes your raw Docker image and turns it into a workstation:

• Smart mounting: It mirrors your local folder into the container in order to save locally but run globally.
• User lock-in: It forces the remoteUser to badprog user so everyone on your team has the exact same experience.
• Eye candy: It even tweaks your VS Code status bar colorsn beccause it’s not just for looks, it’s so you know you’re working inside the matrix!

3. The CI pipeline with Github Actions

To keep things from breaking, we’ve split our GitHub Actions into two high-fiving jobs:

Job 1: job-dockerfile

This is the "raw" test.

We build the image and ask: "Hey, are you actually a ROS 2 image?

Is our user there?

Is the ROS 2 source line present?

If this fails, the party stops here.

Job 2: job-devcontainer

This is the "real world" test.

We use the @devcontainers/cli to spin up the container exactly like VSCode would.

If the workspace isn't where it should be or if the user permissions are wonky, the CI screams "No!"

Conclusion

By splitting your tests between the image foundation and the container orchestration, you’re catching bugs before they even reach your keyboard.

This minimal template is your ticket to a stress-free ROS 2 journey.

Clone it, push it, and watch those green checkmarks light up.

Happy coding, you did it!