Use --remote for acceptance tests run on drone #32299
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
tests/drone/test-acceptance.sh
to the acceptance testrun.sh
--remote
argument to the place it is missing in.drone.yml
Motivation and Context
tests/drone/test-acceptance.sh
is used with arguments in some places, but actually it ignores its arguments. So those places are totally misleading at the moment. It should pass its arguments through torun.sh
when it calls it.The
--remote
argument is to indicate that the system-under-test is "black-box" or "remote" - i.e. we cannot or should not rely on being able to "manipulate it under the hood" by doing local commands from the test script. At the moment, what that means in practice, is that we assume that the SUT already has the testing app enabled, so we do not need to bother trying to enable it, and can do all our setup using the testing app. We should be consistent and always use--remote
when running on drone, because the testing app is indeed pre-enabled and ready.How Has This Been Tested?
CI will show.
Types of changes
Checklist:
Open tasks: