-
Notifications
You must be signed in to change notification settings - Fork 144
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
Support LaunchService injection into pre-shutdown tests. #308
Conversation
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
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.
LGTM!
This allows launch_service
injection in the tests, but #295 is about supporting repeated execution.
Is the idea just to loop using launch_process
or to add some extra functionality to make repeated tests looks nicer?
I was thinking about simply looping, yes. We could also instrument a decorator for our tests that repeats it until it passes or timeout is reached, akin to |
Alright, all green. Going in! @dirk-thomas feel free to comment async. |
@@ -87,6 +87,7 @@ def run(self): | |||
self._test_run.bind( | |||
self._test_run.pre_shutdown_tests, | |||
injected_attributes={ | |||
'launch_service': self._launch_service, |
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.
@hidmic Not directly related to this PR, but do you have any guidance for a process for deprecating 'injected_attributes' from launch_testing? Something like 'put a warning in the next release when someone uses an injected attribute' then in the release after that remove injected attributes?
I think injected_args are better and less confusing in just about every way. They still require the user to know ahead of time what 'magic words' can be added as arguments to a test function, but beyond that they're way less mysterious
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, you could wrap them using a property
that can generate a warning
once if these are used.
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.
@hidmic Yeah - I know how to do the implementation side - my question is more about the administrative side. Do we need a full release of "WARNING THIS WILL BE DEPRECATED" or is it sufficient to add the warning, them actually deprecate once all of OSRF's stuff is updated?
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, forgot to reply. And sorry for the noise, I clearly half read what you wrote before.
I actually don't know what's the deprecation cycle for Python APIs here. What you describe makes sense to me. We'd be looking forward to issuing a DeprecationWarning
in Eloquent and removing the feature entirely on F-Turtle. @dirk-thomas any thoughts?
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.
If a deprecation cycle is technically feasible it is certainly preferred to give users time to migrate.
@@ -332,6 +332,10 @@ def __on_shutdown_process_event( | |||
self, | |||
context: LaunchContext | |||
) -> Optional[LaunchDescription]: | |||
typed_event = cast(ShutdownProcess, context.locals.event) | |||
if not typed_event.process_matcher(self): | |||
# this event whas not intended for this process |
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.
Spelling.
Also that this
is used twice but references different entities is a bit hard to read.
Precisely what the title says. Closes #295.