-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add testing for L0_iterative_tutorial #7176
base: main
Are you sure you want to change the base?
Conversation
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 you think it make sense to make a more general structure for tutorial's tests in this PR or follow up PRs?
e.g. qa/L0_iterative_tutorial/test.sh
-> L0_tutorials/iterative_tutorial/test.sh
@oandreeva-nv I think we did this for Python backend but the feedback was that it makes it harder to determine which part of the test is flaky since they are all bundled together. Additionally, the tests can be executed in parallel if they are separate. |
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
qa/L0_iterative_tutorial/test.sh
Outdated
@@ -0,0 +1,49 @@ | |||
# Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES. All rights reserved. |
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.
nit similar to Olga's comment - can we rename this to L0_tutorial_iterative_scheduling
(and future L0_tutorial_*
) so we can quickly identify/group the tutorial repo based tests?
Similar to L0_backend_{identity,python,...}
RET=0 | ||
|
||
# Install the dependencies | ||
pip3 install "transformers[torch]" |
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.
Should we lock down the version to whatever worked while testing to avoid unexpected breakage?
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | ||
|
||
rm -rf tutorials | ||
git clone https://github.com/triton-inference-server/tutorials.git -b ${TUTORIAL_REPO_TAG} --depth 1 |
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.
Should we default TUTORIAL_REPO_TAG
for ergonomics of local testing (docker exec devel) outside of a pipeline? Something like this
TUTORIAL_REPO_TAG=${TUTORIAL_REPO_TAG:-"main"}
triton-inference-server/tutorials#90