The exact wording is to be further refined, current draft mostly concerns about the general idea of what would be included.
Continous Integration
[CI.PLATFORM] REQUIREMENT: All CI should be implemented using GitHub Actions or an CI platform that appripriatly interacts with the code control system.
[CI.TEST] REQUIREMENT: CI must execute appripriate testing of reasonable scope tagged with each commit, and must fail with test cases.
[CI.TEST.CROSS_PLATFORM] REQUIREMENT: CI enabled tests must be executed across major platforms if appripriate.
[CI.TEST.CROSS_COMPILER_FAMILIES] REQUIREMENT: CI enabled tests must be executed across major compiler families if appripriate.
[CI.TEST.CROSS_COMPILER_VERSIONS] RECOMMENDATION: CI enabled tests should be executed across support major versions of appripriate compiler families.
[CI.DURATION_PER_COMMIT] RECOMMENDATION: CI pipeline associated with commits should finish in a reasonable amount of time.
[CI.SCHEDULED_TEST] RECOMMENDATION: CI enabled checks should run periodically across the entire repository.
[CI.SCEDULED_TEST_NOTIFY_FAILURE] REQUIREMENT: There must be a established protocol to report CI failure (e.g. opening a GitHub issue) when scheduled CI fails.
I’m going to revive this topic and narrow the scope since @river 's original PR on this subject has been merged and we have, in the interim, set up significant CI (many thanks to those responsible, overall it’s great!).
So the specific subject I’d like to discuss is the review-dog ci. It seems to have a lot of really awful formatting suggestions for code that um, I’m going to reject. You can look at the linked scope library PR below to see some of the weird ideas it suggests. For now in scope I’ve just turned the error level to ‘none’ because it’s not helping. Note that we’re also running clang-format, which has it’s own issues – but with that one I can simply block it using clang-format off comments.
One thing I’m wondering is if we need some tuning of settings on both of these formatters – maybe another cppnow project?
btw – here’s an example of what clang-format wants to do (green is suggestion – red is existing). This can be tweaked with rules – although it can be painful.
Definitely, go for it, the linting config is not set-in-stone at all.
I am more than happy to push my proposal in, I am busy with interviews right now, but most of the ideas are on the table and their implementation should all be in exemplar.
I think a note I want to give here CI requirement is very tightly coupled with testing requirement. For which has not been setup yet. We might want to define CI requirements after (or along with) a minimum testing requirement.
