-
Notifications
You must be signed in to change notification settings - Fork 142
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
Migrates legacy launch API tests #167
Conversation
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
I think it makes sense to get rid of the legacy API regardless of what comes out of the launch based testing framework work. Unrelated functionality I had to add I think could still be useful outside testing, do tell if you think otherwise. |
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 looks pretty good to me so far, though I had a some questions during review.
if all(status == 'succeeded' for status in self.__tests.values()): | ||
return EmitEvent(event=Shutdown(reason='all tests finished')) | ||
|
||
def add_fixture_action(self, launch_description, action, required=False): |
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.
Passing the launch_description in here was a bit off-putting to me at first, but I see the reason for it now, though I wish it were more transparent what was happening. If you look just at the calling code (like at one of the converted tests), you don't get a since as to what is being done to the launch description, you can assume it's adding the fixture/test/output_test or whatever, but I hadn't imagined it would add more actions until reading the code for it here.
A possible alternative would be to make this function simply generate and return a list of actions to be added, rather than adding them directly. Though I'm not sure if the launch description is required within this function in any other cases. For example, it might look like:
my_test_exec_action = ExecuteProcess(...)
fixture_action = lts.create_fixture_action(my_test_exec_action)
ld.add_action(fixture_action)
In that example fixture_action
might be just the original action or a GroupAction
that consists of several things.
I'm not 100% sold on my approach either, as I wouldn't be able to know without an example or very good docs if I should add the original action or just the result of create_fixture_action()
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.
Passing the launch_description in here was a bit off-putting to me at first...
It sort of is to me as well, but as I said before, I was trying to minimize the amount of code changes (because it's not at all unlikely we end up ditching this in the near future) and thus I kept the API the way it was.
A possible alternative would be to make this function simply generate and return a list of actions to be added, rather than adding them directly.
That is an option, sure. Another easy one (easy to use I mean) would be to have a LaunchTestDescription
along with the LaunchTestService
and make them wrap the LaunchDescription
and LaunchService
respectively. Not sure if it makes sense to spend time polishing this API though.
Co-Authored-By: hidmic <[email protected]>
- Emit ExecutionComplete events on demand. - Shutdown OpaqueCoroutine gracefully. - Fix failing test cases. Signed-off-by: Michel Hidalgo <[email protected]>
Running CI for all related PRs using pinned FastRTPS: |
To cope with more test cases. Signed-off-by: Michel Hidalgo <[email protected]>
62d58ac
to
07d55f8
Compare
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
@mjcarroll @sloretz @wjwwood I'm a bit unsure on how to handle bad exit codes upon shutdown in a true cross platform way, thus I'm blatantly ignoring them. Not very proud, but I can't figure out how to do better than that. |
Signed-off-by: Michel Hidalgo <[email protected]>
d26d890
to
ea034a2
Compare
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
So, we have a problem with FastRTPS talking to Opensplice and Connext on Windows. Looks like we have an issue tracking it (and someone suggesting that FastRTPS v.1.7.1 may be the cure). But since this predates these changes (which have only revealed more issues), in the interest of time I'd say: let's disable the offending test just as we did before, and follow up that issue. We can then come back and re-enable all tests. @mjcarroll @sloretz @ivanpauno thoughts? |
Signed-off-by: Michel Hidalgo <[email protected]>
CI is green! @mjcarroll mind to take a shot at this? We can re-run CI on all platforms right after. |
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 some tiny documentation nits, but otherwise LGTM.
.. code-block:: python | ||
|
||
async def coroutine( | ||
context: LaunchContext, # iff ignore_context is False |
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.
I understand what iff
is in this context, but it may be helpful to be a little bit more explicit. It may also be worth updating the docs for OpaqueFunction
so that they are consistent in this regard.
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.
That makes sense. I've updated the documentation, but I'm not sure what you mean about changing OpaqueFunction
docs.
super().__init__(**left_over_kwargs) | ||
if not asyncio.iscoroutinefunction(coroutine): | ||
raise TypeError( | ||
"OpaqueCoroutine expected a couroutine for 'couroutine', got '{}'".format( |
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.
couroutine -> coroutine
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.
Oops, good catch!
""" | ||
Convenience class for handling an action completion event. | ||
|
||
It may be configured to only handle the completion of a specific action, |
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.
Do we have an example or test for handling specific vs all? I can't seem to find it.
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.
Good point, we do not. Test added.
- Improved OpaqueCoroutine documentation. - Added test for launch.event_handlers.OnExecutionComplete. Signed-off-by: Michel Hidalgo <[email protected]>
Grrr something changed on |
@mjcarroll CI got unstable because (a) I had to rebase We can wait till (b) gets fixed, but I'm afraid more things will get in the way after that. It's fine by me, but that means more delay for these PRs. |
@mjcarroll could you take a look at the dependency fixing PRs? |
Done! |
There was a bug fix in this pr that was unrelated to the original change. @stonier opened a pr for just this change here: I declined it so that we could put it through our typical patch release process. The change is small, @nuclearsandwich FYI. |
Thanks for the ping. I don't mind if the original PR gets re-opened or if we open a new PR explicitly preserving the original commit authors as long as we run Crystal CI on it before merging and releasing. |
Connected to #159. This pull request adds the bare minimum functionality to migrate all tests in ROS 2 core packages that make use of the legacy launch API. May eventually face deprecation depending on the path taken after #165.
Some
launch.legacy
tests still remain to be ported, unclear if these should in the first place as such additions may as well fall under the improving test coverage forlaunch
umbrella.