Wondering about CI bitrot

[cburstedde]

The CI fails occasionally on github workflow updates. @scivision addresses these issues on a regular basis; thanks!

Considering our focus on long-term support: Can we do something to make our CI framework more futureproof and robust against whatever the github CI system may come up with? Is there a way to be long-term compatible with a minimum amount of maintenance?

[scivision]

GitHub updates the runners I think weekly or so. Usually this doesn't break anything, but a couple times a year it does. Also when Apple updates XCode a few times a year this can disrupt.

To keep it stable I think would require private on-premises CI like Jenkins or GitHub Actions for on-premises. But then those need maintainence.

The issue with such frozen CI runners, is then they are out of date with what end users have. For example macOS with Homebrew is probably the majority of users besides HPC. This updates so often and breaks occur across projects a few times a year.

[cburstedde]

Sounds reasonable! Let's just keep using those CI features that are most promising to be long term stable.

[cburstedde]

I'm keeping this one open. The goal is to stablilize the CI such that by the end of the year it can live on its own without further maintenance. To this end, we may eventually need to go from ubuntu versions to latest.

[cburstedde]

I'm keeping this one open. The goal is to stablilize the CI such that by the end of the year it can live on its own without further maintenance. To this end, we may eventually need to go from ubuntu versions to latest.

I'd like to stay away from bleeding-edge build tool versions in the CI. To be as maintenance free as possible, I'd like to propose to use no newer packages than what's available in Debian stable (unless they are the default of ubuntu-latest or some other generic OS option). Ideally I'd like to stop using version numbers altogether to avoid technical debt.

[cburstedde]

If we use github actions with version tags like checkout@v4, they will run out of life at some point and github starts deprecating them. It seems using @main instead solves the problem indefinitely -- as long as github does not change the main branch name.

[cburstedde]

sc is still doing fine! :) I was provoking chrashes on the non-MPI build, which seems to be CI'ed from the autotools builds but currently not from CMake. While this build is rarely relevant, it would be nice to update the CMake CI with one non-MPI build, and if @scivision likes the idea to go for @main in the actions.