Mavros in its own build stage#241
Open
amarburg wants to merge 6 commits intoRobotic-Decision-Making-Lab:mainfrom
Open
Mavros in its own build stage#241amarburg wants to merge 6 commits intoRobotic-Decision-Making-Lab:mainfrom
amarburg wants to merge 6 commits intoRobotic-Decision-Making-Lab:mainfrom
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes Made
This is an experimental PR which isolates the Mavros/Mavlink build in its own (cacheable) build stage. It builds on #220.
Mavros is built in a standalone workspace (
~/ws_mavros) in a build stage. This workspace is then copied into thecistage. Subsequent builds inws_bluethen extend this mavros workspace rather than the base ROS environment.Besides increasing complexity of the build process, the major negative is that more functionality is pulled into the ci stage, specifically:
ws_mavroscan be built and owned by the non-root user.ws_mavrosworkspace is copied into the "ci" stage as a dependency of blue (given mavros would normally would be installed by rosdep anyway if a binary was available)(on further reflection, these aren't strictly required, depending on how pedantic we want to be about what's in/out of the ci stage:
noble-based images include theubuntuuser anyway, this isn't a big deal.robotstage. Appropriate--ignore-keys would need to be added to the call torosdepincirobot.)
I've also committed my
docker-bake.hclto simplify repeatability. I have not updated the Github action to use buildx bake. This conflicts with #266, and if/when that's merged it will require some manual rebasing in this branch.Cross-compile performance
All builds on an i7-11800H, running
docker buildx bake mavros --no-cachewith appropriate platform -- only one platform at a time. Package time are reported by colcon, "total" is the value reported bydocker buildxfor thecolcon buildstep."amd64 bare metal" is a with rolling installed directly onto the same laptop
Raspberry Pis are on a clean distribution of Bookworm 64bit "Lite" (no GUI), with no active or passive cooling on the board (so thermal throttling may be a factor)
Yikes.
n.b. The Pi4 would OOM (even with 8GB of swap), so the job was run with
-j2Testing
Please provide a clear and concise description of the testing performed.