Repository navigation
detect Cppcheck integration issues earlier #417
Description
The last simplecpp bump had to revert two PRs because they did not work with Cppcheck. We need to find a way to detect these issues before integration them downstream.
See https://trac.cppcheck.net/ticket/13635 for downstream issue.
Activity
firewave commentedon Feb 13, 2025
Ideas:
add scheduled jobs with latest simplecpp source to Cppcheck CI
The downside would be there it is disjointed from the PR and we would have to manually check. The feedback would also be delyed and if many things were merged we would not know what caused the issue.
adjust Cppcheck workflows to be triggerable and have an option to use a certain simplecpp version
This would give us feedback within the PR context. It would delay the CI run of the PR though. We could make it not wait on the result and just add a comment to the upstream PR. We could also limit this to after it was merged - doing a fix-up afterwards would be fine IMO. That would mainly preserve the autonomy from Cppcheck.
Tal500 commentedon Feb 16, 2025
A simple start - add a cppcheck workflow step that clone the upstream cppcheck repo, build it with the local simplecpp version, and run
make testdanmar commentedon Feb 19, 2025
I don't have a strong opinion about the ideas.. but imho the scheduled work option will not work because as you say "disjointed from the PR and we would have to manually check"
firewave commentedon Feb 23, 2025
Yes. I just wrote them down as I was thinking about it and during that it became obvious the second case is the only way to go.
firewave commentedon Oct 13, 2025
Since any change will ultimately lead to a downstream PR at some point, we could create a downstream schedule which automatically generates/updates a PR when changes are detected. That would be how cppcheck-opensource/cppcheck#7659 might come into play. It would still be disjoint but eliminate some manual steps.