CI: Update containers and migrate to newer tooling

[TSC21]

Solved Problem

Update the containers to use more recent OS versions and tooling. This also allows to solve some flash problems by bumping the version of GCC to 11.

Solution

• Add updated container images for GitHub Actions workflows.
• Refactor CI configurations to migrate from ROS Melodic to Noetic.
• Remove Python 2 shebang in the mavros tests, to allow Python 3 to be used instead.
• Others as per reported errors and build failures.

Changelog Entry

For release notes:

Feature: Updated GitHub Actions container images to newer versions (jammy, 2024-05-17).
Migration: Moved MAVROS tests from ROS Melodic to ROS Noetic.
Documentation: Clarify CI configurations on docs.px4.io.

Alternatives

Well, we can always keep using legacy container versions and continue trying to optimize the flash space.

Test coverage

• Check the CI runs

Context

N.A.

[TSC21]

@dagar would appreciate your review here. I can see some sim tests consistently failing but they are also seen failing without the changes on the containers (in other PR runs). Might be reasonable to explore ways of solving those failures, but potentially in a separate PR (I am mostly interested on getting the plane tests up, running and passing ASAP). Other than that, I believe this PR should be ready to go.

[AlexKlimaj]

Do you want to update the tools/setup/ubuntu.sh installed GCC toolchain to match as well? We save some flash by upgrading. Also makes compatibility with cortex-debug work again since it requires a newer GDB version.

[TSC21]

Do you want to update the tools/setup/ubuntu.sh installed GCC toolchain to match as well? We save some flash by upgrading. Also makes compatibility with cortex-debug work again since it requires a newer GDB version.

Yes. If you already have a suggestion on what to change there, please feel free to push a commit directly to this branch.

[AlexKlimaj]

I have this PR open, but there was the issue of updating the CI tools to match. #22568

[TSC21]

I have this PR open, but there was the issue of updating the CI tools to match. #22568

I would say we don't need an exact match - as long as we use GCC 10 or above we should be ok either using GCC 11 (default on Ubuntu 22.04) or GCC 13.

[dagar]

I have this PR open, but there was the issue of updating the CI tools to match. #22568

I would say we don't need an exact match - as long as we use GCC 10 or above we should be ok either using GCC 11 (default on Ubuntu 22.04) or GCC 13.

We need to have one "official" version that we test in CI, use for the QGC builds, and most importantly can point to if they hit some weird edge case, slight flash overflow, etc. Once we bump everything to Ubuntu 24.04 I'd like this to be the packaged arm-none-eabi-gcc version so we can eliminate the custom installation.

That being said, we should absolutely try to keep the compiler support as wide as possible, always keeping up with latest GCC/Clang on the side. There's no reason the default GCC/Clang on most recent-ish distros, MacOS, etc shouldn't "just work", but it's only best effort, if there's ever an annoying problem we can always point to the exact version that's tested across everything.

[TSC21]

I have this PR open, but there was the issue of updating the CI tools to match. #22568

I would say we don't need an exact match - as long as we use GCC 10 or above we should be ok either using GCC 11 (default on Ubuntu 22.04) or GCC 13.

We need to have one "official" version that we test in CI, use for the QGC builds, and most importantly can point to if they hit some weird edge case, slight flash overflow, etc. Once we bump everything to Ubuntu 24.04 I'd like this to be the packaged arm-none-eabi-gcc version so we can eliminate the custom installation.

That being said, we should absolutely try to keep the compiler support as wide as possible, always keeping up with latest GCC/Clang on the side. There's no reason the default GCC/Clang on most recent-ish distros, MacOS, etc shouldn't "just work", but it's only best effort, if there's ever an annoying problem we can always point to the exact version that's tested across everything.

@dagar ok so what do you suggest we do right now? Install GCC 11 on the build scripts, or install GCC 13 or later in the containers? Or can we merge this and take that decision in another PR soon?

[dagar]

Do you want to start with updating/fixing just the MAVROS pieces here?

For actually bumping the compiler version for the firmware builds I'd like to do that in a unified pass where we update Docker, Tools/setup, documentation all together. We also need a sanity check flying those firmware builds across the main architectures. I know it seems paranoid, but there have been subtle problems in the past.

[TSC21]

Do you want to start with updating/fixing just the MAVROS pieces here?

@dagar I can give it a try but this doesn't seem to be a problem inherent to the version of the tooling but rather something in the tests or even in the controller side. Can this be addressed in a separate PR?

For actually bumping the compiler version for the firmware builds I'd like to do that in a unified pass where we update Docker, Tools/setup, documentation all together. We also need a sanity check flying those firmware builds across the main architectures. I know it seems paranoid, but there have been subtle problems in the past.

OK fair enough - I can help with getting a unified update here. @mrpollo @AlexKlimaj maybe you guys can or know someone that can help with the flight testing, specially with MCs?

[AlexKlimaj]

We can test fly multicopter.