-
Notifications
You must be signed in to change notification settings - Fork 146
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
Import apex rostest #209
Import apex rostest #209
Conversation
- Arguments work like regular launch arguments: apex_rostest name_of_test.py arg:=foo - Added a mesasge pump class that will spin some rclpy nodes on a background thread automatically
Add launch arguments to apex_rostest
- Rename apex_rostest to apex_launchtest - Remove rclpy deps from apex_launchtest - Remove launch_ros deps from apex_launchtest - Move ros and rclpy deps into a new package, apex_launchtest_ros - Add two examples to apex_launchtest that don't require ROS - Update tests that used the ROS nodes previously in apex_rostest to use non ROS processes - Update license from "all rights reserved" to apache
Change apex_rostest to apex_launchtest
- Build and test apex_launchtest only - Build and test everything (apex_launchtest + apex_launchtest_ros) - Coverage report
- Git rid of extra sh -c (left over from a copy/paste) - Build jobs only save 'build' and 'install' artifacts - test_all job saves 'build', 'install', 'log', and globs for .coverage files
Add gitlab ci
- Use symlink-install, otherwise coverage we get through subprocess calls ends up in a different place than coverage we get through calling functions directly from tests
Fix coverage report
More output when node dies
- Gave all of these methods the same signature. They can all take ExecuteProcess actions or strings - New util to handle the lookup of process actions in one place
Have IO and Exit Code asserts use the same lookup
* Initial README.md doc and improved example * Address review comments * Describe assertions * Describe arguments * Address second round of review comments * Update README.md One more round of addressing comments
Test xml output
- Do an isolated build from source to catch issues with missing deps - Add a line (commented) that will fail the build if rclpy is a dep for apex_launchtest - Set up job to run on a schedule (schedule will need to be added to CI) because it's very long
- Remove ros2launch dep from apex_launchtest, which should also remove rclpy dep - Add test for the '--show-args' argument - enable CI check for rclpy dep
Remove rclpy from apex_launch
Fix rclpy dep (again)
- This bug happened when all of the processes under test crashed out from under us and we tried to print extra info to help debug the test failure, but at least one of the processes had no output
Apply internal fixes and improvements to public repo
- use the 'source' option for coverage to pick up files not touched by any test. Currently, message_pump and apex_launchtest_ros/__init__.py because we're not running any of the ROS examples
Add coverage on 0% covered files
Signed-off-by: William Woodall <[email protected]>
Signed-off-by: William Woodall <[email protected]>
I'll be merging this without the DCO checker passing because the commits predate our policy, however, I will ask @dejanpan and @pbaughman to just confirm in a comment, that they would have signed-off for the commits that lack the sign-off in the commit message. |
@@ -0,0 +1,129 @@ | |||
# apex_launchtest |
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.
Just as a reminder for our future selves, we need to find a new home for this repo level README.
@@ -0,0 +1,4 @@ | |||
[coverage:run] |
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.
Hmm, we don't do coverage checks, do we? Just wondering if it'd make sense to bring that improvement along with the repo.
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.
We don't collect coverage stats right now in our CI, but it would be nice to have this at some point. I don't know, however, if putting it in the setup.cfg makes sense, as it should be possible to run it with and without. I don't know what the recommended strategy is.
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.
My understanding is that a bunch of different tools may look for a setup.cfg file and should each ignore configuration sections not meant for them. If this is causing a problem with another tool that expects its setup.cfg file to be free of [coverage:run]
sections, we could also move it to a file called .coveragerc
See https://coverage.readthedocs.io/en/v4.5.x/config.html for how 'coverage' uses configuration files
@@ -0,0 +1,30 @@ | |||
#!/usr/bin/env python |
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.
Shouldn't be python3
instead?
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.
It probably shouldn't have a shebang.
We should address the comments you raised when merging it with the existing code, i.e. after this import pr. |
@wjwwood - I confirm that I would've signed off on the commits that lack the sign-off in the commit message |
Thanks @pbaughman for the confirmation. The CI failures are the know @dejanpan just waiting for you to 👍 the commits that weren't signed-off at the time. |
@wjwwood - I confirm that I would've signed off on the commits that lack the sign-off in the commit message |
# This file contains modified code from the following open source projects | ||
# published under the licenses listed below: | ||
|
||
# Software License Agreement (BSD License) |
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.
@wjwwood This doesn't match the license declared in the manifest?
See: #208