Summary
The OPC UA plugin integration job (.github/workflows/opcua-plugin.yml) builds two images from scratch on every run: docker/Dockerfile.gateway (the gateway workspace plus the plugin) and docker/openplc/Dockerfile (the OpenPLC runtime). Both start with a fetch stage that talks to the network four times: apt-get update, apt-get install, two git clones in the OpenPLC image, and the FetchContent download of open62541pp inside colcon build. Any of these can hang or fail on a slow mirror, and when one does the whole job is lost after 20 to 40 minutes of work that had nothing to do with the change under test. A retry loop around apt-get update alone covers one of the four, so it was not kept.
The same fetch stage costs every run the same time whether or not anything in it changed.
Proposed solution (optional)
Publish a base image for this job and build on it:
- a
Dockerfile in the repo (for example docker/Dockerfile.opcua-ci-base) that starts from the ros:<distro>-ros-base image the CI jobs already use, installs the apt packages both images need, fetches open62541pp at the pinned tag into a known path, and carries the OpenPLC sources the runtime image clones
- a workflow that builds and pushes it to GHCR on a schedule (weekly) and whenever that Dockerfile or the pinned versions change, so a run of the integration job never rebuilds it
docker/Dockerfile.gateway and docker/openplc/Dockerfile start FROM that image; the colcon build points FetchContent at the prefetched source (FETCHCONTENT_SOURCE_DIR_OPEN62541PP), so the only network access left in the job is the checkout- the base image workflow is the one place that fetches, and it gets a retry around each fetch, so a mirror hiccup costs a scheduled rebuild and never a PR run
The change to ros:<distro>-ros-base images for the main CI jobs is the same idea one level up.
Additional context (optional)
The read-only build work on the plugin carried a commit that retried apt-get update in Dockerfile.gateway; it was dropped from that branch because it covered one fetch of four and belongs with the rest of the fetch stage here.
Summary
The OPC UA plugin integration job (
.github/workflows/opcua-plugin.yml) builds two images from scratch on every run:docker/Dockerfile.gateway(the gateway workspace plus the plugin) anddocker/openplc/Dockerfile(the OpenPLC runtime). Both start with a fetch stage that talks to the network four times:apt-get update,apt-get install, twogit clones in the OpenPLC image, and the FetchContent download of open62541pp insidecolcon build. Any of these can hang or fail on a slow mirror, and when one does the whole job is lost after 20 to 40 minutes of work that had nothing to do with the change under test. A retry loop aroundapt-get updatealone covers one of the four, so it was not kept.The same fetch stage costs every run the same time whether or not anything in it changed.
Proposed solution (optional)
Publish a base image for this job and build on it:
Dockerfilein the repo (for exampledocker/Dockerfile.opcua-ci-base) that starts from theros:<distro>-ros-baseimage the CI jobs already use, installs the apt packages both images need, fetches open62541pp at the pinned tag into a known path, and carries the OpenPLC sources the runtime image clonesdocker/Dockerfile.gatewayanddocker/openplc/DockerfilestartFROMthat image; the colcon build points FetchContent at the prefetched source (FETCHCONTENT_SOURCE_DIR_OPEN62541PP), so the only network access left in the job is the checkoutThe change to
ros:<distro>-ros-baseimages for the main CI jobs is the same idea one level up.Additional context (optional)
The read-only build work on the plugin carried a commit that retried
apt-get updateinDockerfile.gateway; it was dropped from that branch because it covered one fetch of four and belongs with the rest of the fetch stage here.