ci: retry the network reads our own CI steps make

[bburda]

Pull Request

Summary

Every CI job reads from the network before anything of ours is built, and rosdep update is the one of those reads this branch can wrap: it fetches the distribution index from raw.githubusercontent.com. A reset connection there fails the whole job with an error that has nothing to do with the change under test. Two jobs on two pull requests failed that way within an hour on the day this branch was opened, both on rosdep update with Connection reset by peer.

rosdep update now gets three attempts five seconds apart in every workflow step that calls it (ci.yml, quality.yml, opcua-plugin.yml). The ctcache install in the clang-tidy job gets the same loop: it is a git+https URL, so pip runs git clone in a subprocess to fetch it, and pip's own --retries only covers its HTTP session. A genuine failure still ends the job after the last attempt with its own error text; the loop only names the attempt.

The release-asset download in .github/actions/ros-apt-source gets a wider window. It already retried, but only for about 18 seconds, and a job on this branch died when GitHub answered 500 to all six attempts. That download is the one fetch in the action with nothing to fall back to: the version lookup above it can use the pinned value, but a 5xx on the .deb ends the step, and setup-ros then has no apt source, so the build stops at colcon: command not found. Measured against a server that answers 500 every time, the old flags make 6 attempts over 18 s and the new ones make 9 over 131 s.

One read stays unprotected, and it runs earlier than any of these. ros-tooling/setup-ros@v0.7 removes /etc/ros/rosdep/sources.list.d/20-default.list and then runs sudo rosdep init once, with no retry around it (src/setup-ros-ubuntu.ts:135-137 in the action). That call fetches 20-default.list from raw.githubusercontent.com, the same host that fails here, and it happens before the step this branch touches, so a reset there still ends the job. Wrapping it would mean not using the action, which is a larger change than this one.

apt-get update is left alone on purpose. apt has defaulted Acquire::Retries to 3 since 2.3.2. Measured on the three images this repository builds in, a fetch against a dead endpoint makes the same four attempts with the flag and without it:

image	apt	no flag	-o Acquire::Retries=3	-o Acquire::Retries=0
ubuntu:jammy	2.4.14	4 attempts	4 attempts	1 attempt
ubuntu:noble	2.8.3	4 attempts	4 attempts	1 attempt
ubuntu:resolute	3.2.0	4 attempts	4 attempts	1 attempt

---

Issue

• none: a CI hardening with no behaviour change in the repository's code

---

Type

• Bug fix
• New feature or tests
• Breaking change
• Documentation only

CI configuration only.

---

Testing

• Every workflow file still loads as YAML.
• The diff against main is the 11 rosdep update call sites, the ctcache install, and the curl flags plus their comment in the apt-source action. No other line is touched.
• The loop was exercised the way the workflow runs it. Each step body was read out of the YAML and run under the shell GitHub Actions uses (bash --noprofile --norc -eo pipefail), with a stand-in rosdep and pip3 that fail a set number of times. set -e does not stop the step on a failed attempt: with zero, one or two failures the step ends at 0 and the following rosdep install still runs; with three failures the step ends at 1 and the last error is visible.

---

Checklist

• Breaking changes are clearly described (and announced in docs / changelog if needed)
• Tests were added or updated if needed
• Docs were updated if behavior or public API changed