-
Notifications
You must be signed in to change notification settings - Fork 219
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
Fix #346, Adds library build, functional, and coverage test to CI #403
Fix #346, Adds library build, functional, and coverage test to CI #403
Conversation
@astrogeco we seem to be skipping a few pull requests that got submitted but aren't marked ready for CCB. Can we just assume if they are new they should be discussed (as long as they aren't tagged w/ WIP)? |
Or review everything that isn't marked NOT ready? |
Good point, though we've been keeping the agenda pretty full despite the fact we're missing those. Ill take a look. |
d97afc0
to
2373364
Compare
Rebased and updated per #404... |
2373364
to
6967079
Compare
6967079
to
af96893
Compare
Now cppcheck is --quiet to clean up the CI log. |
af96893
to
221fea2
Compare
It is great to see that this is being prepared. I have been waiting for it since I opened the macOS support branch. I have a few comments on what is being implemented here. They are in no way intended to be blocking the current changeset which is a great enhancement. From quite some experience of maintaining private and public CI setups, I would highly recommend you to not put your CI commands directly into the I have seen many options but the following three are on my active list: a) Good old Makefile. Extremely typical example I have been working with recently: doorstop/Makefile. All commands can be put into the tasks such as: The experience taught me and my colleagues that this approach does not scale well when you get a large number of tasks and when you have to parametrize your script in advanced way. b) Ansible playbooks I am sure you are aware of Ansible playbooks. This is what @AlexDenisov and I are using in our Mull project with a great convenience as we have to scale our tool across many versions of OSes and LLVM. Please see examples: https://github.com/mull-project/mull/blob/master/infrastructure/macos-playbook.yaml. c) Invoke This is a Python tool which gives you a combination of Makefile tasks functionality and Python scripting. See the example here: https://github.com/stanislaw/FileCheck.py/blob/master/tasks.py. What is run by CI can run 1-1 locally on all supported platforms: Linux, macOS and Windows. These days, If I had to start a new project equivalent in scale, importance and complexity to such of the nasa/osal, I would go for a combination of the approaches b) and c): Keeping the infrastructure/dependencies logic in Ansible playbooks (the Mull example above) while having all tasks such as I hope this advice could help you in one or another way. I have some more comments about the changeset and I will put them in the form of specific comments. |
src/bsp/pc-linux/build_options.cmake
Outdated
# Note - although GCC understands the same flags for compile and link here, this may | ||
# not be true on all platforms so the compile and link flags are specified separately. | ||
if (NOT CMAKE_CROSSCOMPILING) | ||
set(UT_COVERAGE_COMPILE_FLAGS -pg --coverage) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be non-portable:
clang: error: the clang compiler does not support -pg option on versions of OS X 10.9 and later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another note, even if it might be beyond the scope of this changeset. Usually such functionality is created in separate files like cmake/coverage.cmake
to not mix the logic of the targets with the logic of the coverage.
The same applies to things like clang-format
, clang-tidy
, other code linters, spell checking, etc.
One good example can be found here: https://github.com/StableCoder/cmake-scripts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #420
@stanislaw Great suggestions, thanks! Definitely a goal to improve. |
221fea2
to
6e1f096
Compare
Rebased on master |
CCB 20200422 - APPROVED |
Describe the contribution
Fix #346, Adds library build, functional, and coverage test to CI
Testing performed
Steps taken to test the contribution:
Expected behavior changes
Just adds tests to CI
System(s) tested on
Additional context
None
Third party code
None
Contributor Info - All information REQUIRED for consideration of pull request
Jacob Hageman - NASA/GSFC