Closed rob-clarke closed 3 years ago
The GitHub action jobs currently take between a few minutes and a few hours. The multiple hours for the build is primarily due to building ros1_bridge
from source through emulation. Even on native hardware this took about an hour. Once MAVROS gets ported to ROS2, and the binaries become available, this should drop significantly. The total build time is likely to be constrained by building PX4 and its Gazebo plugins, which currently takes about 30 mins on the runner instances.
GitHub action caching may be able to speed up future builds, but I don't think the buildx cache actually fits in the allowed 5GB. The main culprit of this is PX4's dev image which has a lot of supporting files. It could likely be slimmed down significantly.
A significant change has been made to the structure of the Dockerfiles for the *-px4-*
images. It makes use of a Dockerfile syntax extension to enable header-style includes. As of yet I have not seen buildx
complain about this.
The aforementioned dependency issues have also resulted in the addition of REGISTRY
and VERSION
build arguments to some Dockerfiles. When not using the docker
driver, buildx
will always pull FROM
lines from a registry so to ensure correct version and source, the build arguments need to be added to images that depend on other starling-*
images.
This PR adds a github action to automate updating and deploying images to Docker Hub. A dedicated bot user has been added with access to the
uobflightlabstarling
repo. Login details are stored as repository secrets and used in the action.The core of the action is a set of calls to
docker buildx bake
. This command does multi-platform, multi-image builds in parallel. Unfortunately, it does not capture dependencies between images so some witchcraft has been enacted to ensure that versioning is maintained. See the readme for further details.A set of local scripts are provided which also invoke the
buildx bake
method. This provides an alternative to the current Makefile system which should be more easily extendible for future images. Local multi-platform builds have a lot of extra faff associated and at present, they are broken. However, the GitHub action runners don't appear to have a problem with the multi-platform builds so this will be raised as a separate issue.With a local ARM64 machine, it should be possible to use the native-node
buildx
methodology detailed here (Strategy 2)Closes #12