Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI / continuous testing would be nice #65

Open
4 tasks
fenugrec opened this issue Feb 11, 2021 · 4 comments
Open
4 tasks

CI / continuous testing would be nice #65

fenugrec opened this issue Feb 11, 2021 · 4 comments

Comments

@fenugrec
Copy link
Owner

fenugrec commented Feb 11, 2021

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
Copy link
Contributor

cfehse commented Feb 12, 2021

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
Copy link
Contributor

cfehse commented Feb 25, 2021

@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
Copy link
Owner Author

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
Copy link
Contributor

cfehse commented Feb 27, 2021

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

So decision made: 1 workflow definition per architecture.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants