CI: strip broken repo.pdi.dev apt source from CI container before apt-get update

[julianlitz]

The CI is failing since 2 weeks.
E: The repository 'https://repo.pdi.dev/ubuntu noble Release' does not have a Release file.
Claude analysis:

Root cause

We don't reference repo.pdi.dev anywhere in our own workflow/action files.
The source comes from the ghcr.io/gyselax/gyselalibxx_env:latest container
image we pull for every job — it ships a preconfigured apt source pointing at
repo.pdi.dev/ubuntu, which no longer serves a valid Release file for
noble (PDI's current documented path is repo.pdi.dev/pdi-main.ubuntu).

Since we pin that image to :latest, an upstream rebuild of
gyselalibxx_env silently broke our CI with zero commits on our side.

Fix

Strip any apt source referencing pdi.dev before running apt-get update,
in every composite action that does an update:

• .github/actions/build/action.yml
• .github/actions/cuda_build/action.yml
• .github/actions/test/action.yml
• .github/workflows/main.yml (clang-format job)

The guard is a no-op if no matching source file exists, so it's safe to keep
long-term as defensive hardening against the same class of upstream breakage.

Follow-up (not in this PR)

• Consider pinning gyselalibxx_env to a digest instead of :latest so an
  upstream image change can't silently break CI again.
• Consider filing an issue against gyselax/gyselalibxx_env — their PDI apt
  source appears broken for anyone using that image, not just us.

Merge Request - GuideLine Checklist

Guideline to check code before resolve WIP and approval, respectively.
As many checkboxes as possible should be ticked.

Checks by code author:

Always to be checked:

• There is at least one issue associated with the pull request.
• New code adheres with the coding guidelines
• No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

If functions were changed or functionality was added:

• Tests for new functionality has been added
• A local test was succesful

If new functionality was added:

• There is appropriate documentation of your work. (use doxygen style comments)

If new third party software is used:

• Did you pay attention to its license? Please remember to add it to the wiki after successful merging.

If new mathematical methods or epidemiological terms are used:

• Are new methods referenced? Did you provide further documentation?

Checks by code reviewer(s):

• Is the code clean of development artifacts e.g., unnecessary comments, prints, ...
• The ticket goals for each associated issue are reached or problems are clearly addressed (i.e., a new issue was introduced).
• There are appropriate unit tests and they pass.
• The git history is clean and linearized for the merge request. All reviewers should squash commits and write a simple and meaningful commit message.
• Coverage report for new code is acceptable.
• No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.u

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.50%. Comparing base (70eb7c7) to head (56fa236).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #322   +/-   ##
=======================================
  Coverage   97.50%   97.50%           
=======================================
  Files          79       79           
  Lines        8643     8643           
=======================================
  Hits         8427     8427           
  Misses        216      216           

☔ 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.

[mknaranja]

Looks good. I'd merge this here or do you see the change on the gysela side shortly upcoming @EmilyBourne ?

[EmilyBourne]

@tpadioleau can you have a look at this?

[tpadioleau]

It seems to work so let's go. I would advise you to consider having your own docker image. If on the Gyselalib++ side we do an update that breaks your CI that would be a little weird to me.

[mknaranja]

@tpadioleau You are right. Yet, on the short to mid term range, everything we target is the itegration into Gysela -- as intended when I started to work with EoCoE ;-) I told Emily that you could make adaptations in that direction directly in the repo. So, for the moment, I think it is fine. If there anyway is a change on the Gysela side as Julian suggested, we could also do some minor adaptation here.