CI / continuous testing would be nice

fenugrec / freediag

OBD2 scantool

GNU General Public License v3.0

336 stars 75 forks source link

CI / continuous testing would be nice #65

Open fenugrec opened 3 years ago

fenugrec commented 3 years ago

from PR #64 , the ability to test compilation on MSVC + borland + mingw automatically would be nice.

[ ] run diag_test binary for some internal tests
[ ] run the subset of ctest tests that don't require a hardware interface (currently ctest -I 3 ...)
[ ] running with valgrind for bonus points
[ ] cppcheck / other static checker for more bonus

cfehse commented 3 years ago

test compilation on MSVC + borland + mingw

Borland could be a bit of a problem probably because it may not be installed on the test runner.
Linux build should be tested as well I think.

running with valgrind for bonus points cppcheck / other static checker for more bonus

Yes that would be done in a secound step.

cfehse commented 3 years ago

@fenugrec

Which kind of approach would you prefer for the github action workflow:

A more "native" and "splitted" approach as for example here: https://github.com/danmar/cppcheck/tree/main/.github/workflows

Or a cmake based "all in one" definition as for example here: https://github.com/cristianadam/HelloWorld/tree/master/.github/workflows

fenugrec commented 3 years ago

A more "native" and "splitted" approach as for example here:

If it's a comparable amount of work and functionality, I think I prefer the "split" approach - a bit easier to digest and work on, perhaps ? If there are reasons to prefer the second, I could be convinced.

cfehse commented 3 years ago

I just asked for personal preference. I would tend to "split" approach as well.

So decision made: 1 workflow definition per architecture.