ci: fix SonarScan — sonarcloud-github-c-cpp action was deleted

[nbbrooks]

Description

The rolling-ci-ccov-sonar job fails in ~3 seconds, at workflow-resolution time, before anything is built:

##[error]Unable to resolve action sonarsource/sonarcloud-github-c-cpp, repository not found

SonarSource deleted the sonarcloud-github-c-cpp repository — https://github.com/SonarSource/sonarcloud-github-c-cpp now 404s, so .github/workflows/sonar.yaml can never resolve its own action.

Migration path upstream:

Action	State
SonarSource/sonarcloud-github-c-cpp	deleted (404) ← what we pin
SonarSource/sonarqube-github-c-cpp	archived 2025-10-01
SonarSource/sonarqube-scan-action	active (v8.2.1, pushed 2026-07-22)

The old behavior is carried forward as the deprecated-c-cpp sub-action.

Why this is a safe drop-in

sonarqube-scan-action/deprecated-c-cpp keeps the same contract as the deleted action:

• same composite-action interface (no inputs required)
• installs both sonar-scanner and build-wrapper
• defaults SONAR_HOST_URL to https://sonarcloud.io when unset
• appends the scanner's bin dir to $GITHUB_PATH

That last point matters: the next step runs a bare sonar-scanner -X --define project.settings=..., and it keeps working unchanged because the action still puts the binary on PATH.

Why this went unnoticed

sonar.yaml triggers on: push, so it only runs for branches pushed to moveit/moveit2 itself — PRs from forks never fire it. Most contributions come from forks, so a workflow that cannot resolve its own action has been silently red for anyone pushing a branch directly.

⚠️ This does not turn the job green — there is a second, older failure behind it

Full disclosure after pushing: with the action resolving, the job now runs 1m27s (was 3s) and gets all the way through setup_rosdep, setup_upstream_workspace, and after_setup_upstream_workspace before failing at the next step:

install_upstream_dependencies
$ rosdep install -q --from-paths .work/upstream_ws/src --ignore-src -y | grep -E '(executing command)|(Setting up)'
ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies:
moveit_resources_panda_moveit_config: No definition of [parallel_gripper_controller] for OS version [noble]

Root cause chain (traced 2026-08-03):

1. osrf/docker_images#878 — "Reenable rolling using resolute as base image" — was closed completed 2026-07-09. ros:rolling-ros-base is now Resolute. (The comment in ci.yaml citing Carefully consider return types #878 as an open blocker is therefore stale.)
2. .docker/ci/Dockerfile does FROM ros:${ROS_DISTRO}-ros-base, so it started building on Resolute — and immediately broke, because it hardcodes clang-format-14, which Resolute does not package (it ships 17–22; default candidate is 21):

   E: Unable to locate package clang-format-14
   

3. Consequently every docker.yaml run has failed since ~2026-07-13, and the published moveit/moveit2:rolling-ci is stale — still the last successful noble build.
4. sonar.yaml pins that stale noble image, so moveit_resources_panda_moveit_config can't resolve parallel_gripper_controller, which has no noble rosdep definition (moveit2.repos pulls moveit_resources from source at ros2 HEAD, where that dependency is declared).

SonarScan has in fact been failing on main continuously since 2025-07-22 (last green run), so this PR is peeling the outer layer of a long-broken workflow rather than restoring it single-handedly.

So the second layer is really a clang-format-14 pin in .docker/ci/Dockerfile. Unpinning it is not purely mechanical: Format CI also installs clang-format-14, and moving to a newer clang-format changes formatting output and would require a repo-wide reformat. That's a maintainer decision about which version MoveIt standardizes on, so it is deliberately out of scope here.

Once the image builds on Resolute again, sonar.yaml should work unchanged — and the rolling-resolute special case in ci.yaml (which omits DOCKER_IMAGE precisely because no Resolute base existed) could likely be folded back into the normal rolling-ci job.

This change is still worth landing on its own: an unresolvable action is a hard stop that hides everything behind it, and removing it is what made the real blocker visible.

Note on verification

The scan step itself is gated on steps.ici.outputs.target_test_results == '0' and needs SONAR_TOKEN, so it can't be exercised end-to-end until the image issue above is also resolved. What is verified here is that the action now resolves and the job proceeds through setup — confirmed by the run on this branch reaching install_upstream_dependencies.

Checklist

• Required by CI: Code is auto formatted — CI config only, no source changed
• Extend the tutorials / documentation — not applicable
• Document API changes relevant to the user in the MIGRATION.md notes — not applicable
• Create tests, which fail without this PR — not applicable
• Include a screenshot if changing a GUI — not applicable

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.26%. Comparing base (f737f20) to head (2ce54df).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3808      +/-   ##
==========================================
+ Coverage   46.21%   46.26%   +0.05%     
==========================================
  Files         726      726              
  Lines       59510    59511       +1     
  Branches     7623     7622       -1     
==========================================
+ Hits        27497    27524      +27     
+ Misses      31845    31820      -25     
+ Partials      168      167       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.