Skip to content
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

chore(tests): added makefiles for testing workflow tests locally #11509

Closed
wants to merge 1 commit into from

Conversation

chahatsagarmain
Copy link
Contributor

@chahatsagarmain chahatsagarmain commented Jan 11, 2025

Description of your changes:
Issue #11494
Added makefiles for tests and setup each test locally .

Checklist:

Copy link

Hi @chahatsagarmain. Thanks for your PR.

I'm waiting for a kubeflow member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Copy link
Contributor

@DharmitD DharmitD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

Thanks!

@DharmitD
Copy link
Contributor

/ok-to-test

@hbelmiro
Copy link
Contributor

@anishasthana you may like to review this.

@jgarciao
Copy link

Could you document how to launch the tests in https://github.com/kubeflow/pipelines/blob/master/test/README.md ?

@hbelmiro
Copy link
Contributor

@chahatsagarmain I added one more item to the issue's acceptance criteria.

  • Workflows need to be updated to use the new make targets

@google-oss-prow google-oss-prow bot removed the lgtm label Jan 19, 2025
@mahdikhashan
Copy link
Member

hello @chahatsagarmain , following up with our chat on slack, would you please make sure that this command (make test-requirements) is addressed in the makefile correctly?

related commit in parallel pr:

ce7f54c

it should point to the test-requirements.sh in the dir .github/resources/scripts/.

thanks for your collaboration in advance.

cc: @hbelmiro

Copy link
Contributor

@hbelmiro hbelmiro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chahatsagarmain please don't forget the actions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add the missing .github/workflows/presubmit-backend.yml to on.pull_request.paths.

@@ -53,4 +53,4 @@ jobs:
run: pip install -r ./test/sdk-execution-tests/requirements.txt

- name: Run component YAML tests
run: ./test/presubmit-component-yaml.sh
run: make sdk-component-yaml
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You missed the setup for this one.

export KFP_ENDPOINT="http://localhost:8888"
export TIMEOUT_SECONDS=2700
pytest ./test/sdk-execution-tests/sdk_execution_tests.py --asyncio-task-timeout $TIMEOUT_SECONDS
make sdk-execution
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You missed the setup for this one.

@@ -33,4 +33,4 @@ jobs:
run: pip install yapf

- name: Run YAPF SDK Tests
run: ./test/presubmit-yapf-sdk.sh
run: make sdk-yapf
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You missed the setup for this one.

Makefile Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rename them to have test- in the beginning of their names so it will be easier for contributors to find them.
For example, backend-test-flip-coin -> test-backend-flip-coin.

@hbelmiro
Copy link
Contributor

/ok-to-test

Copy link

Approvals successfully granted for pending runs.

@hbelmiro
Copy link
Contributor

hello @chahatsagarmain , following up with our chat on slack, would you please make sure that this command (make test-requirements) is addressed in the makefile correctly?

related commit in parallel pr:

ce7f54c

it should point to the test-requirements.sh in the dir .github/resources/scripts/.

thanks for your collaboration in advance.

cc: @hbelmiro

@mahdikhashan as per #11512 (comment), you need to add the new target in your PR, otherwise it won't pass the CI and can't get merged.

@hbelmiro
Copy link
Contributor

/ok-to-test

Copy link

Approvals successfully granted for pending runs.

@hbelmiro
Copy link
Contributor

/ok-to-test

Copy link

Approvals successfully granted for pending runs.

@hbelmiro
Copy link
Contributor

/ok-to-test

Copy link

Approvals successfully granted for pending runs.

@hbelmiro
Copy link
Contributor

@chahatsagarmain can you please rebase?

@chahatsagarmain
Copy link
Contributor Author

@hbelmiro I think its already up to date with latest master commit

Copy link
Contributor

@hbelmiro hbelmiro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@google-oss-prow google-oss-prow bot added the lgtm label Feb 20, 2025
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: hbelmiro
Once this PR has been reviewed and has the lgtm label, please assign zijianjoy for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Comment on lines 3 to 6
.PHONY: create-kind-cluster
create-kind-cluster:
kind create cluster --name kfp --image kindest/node:v1.29.2 --wait 5m && \
kubectl version --client --short
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this used? Or is this meant for local set up? If the latter it might be worth adding this to the readme

test/README.md Outdated
Comment on lines 86 to 90

4. Install the necessary dependencies for the test by running the command `make setup-{test_name}`. The steps for setting up dependencies are defined in the `Makefile.setup.mk` file.

5. Execute the test using command `make {test_name}` , all the test that can be run using Make commands are mentioned in `Makefile`.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aren't these meant to replace the "## Running Tests Locally with Kind" section entirely? or at the least the user is likely going to follow one approach or the other, but not both, so we can document it such that we tell the user "you can use the make by doing xyz steps, or you can run it manually by doing abc steps"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can replace the "## Running Tests Locally with Kind" section entirely.

Comment on lines +53 to +54
sudo apt-get update && \
sudo apt-get install protobuf-compiler -y && \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

putting apt-get in a make file here is not a good idea, we should keep this scoped to the environment, this should be handled in the github action (preferably as it's own step), and the user should install this themselves (and we should provide docs as pre-requisites)

for example, if the intent of the pr is to allow users to run these locally, what if they are not using a debian os? we should try to be as platform agnostic as we can (this applies to any make make command here that's using apt-get)

Copy link
Contributor

@hbelmiro hbelmiro Feb 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HumairAK The PR's intent is to allow contributors to find all tests in one place using make commands.

putting apt-get in a make file here is not a good idea, we should keep this scoped to the environment, this should be handled in the github action (preferably as it's own step), and the user should install this themselves (and we should provide docs as pre-requisites)

for example, if the intent of the pr is to allow users to run these locally, what if they are not using a debian os? we should try to be as platform agnostic as we can (this applies to any make make command here that's using apt-get)

I agree 100%. At the same time, keeping this in the GitHub action kind of goes against the reason for this PR.
How about leaving it in the make file for now, but adding a verification to check if it's running on debian before running any command? We could add compatibility with other SOs, like Fedora and macOS, in a follow-up PR/issue.

is_debian() {
  # Check via /etc/os-release (most reliable)
  if [ -f /etc/os-release ]; then
    if grep -q 'ID=debian' /etc/os-release; then
      return 0
    fi
  fi

  # Fallback check for /etc/debian_version
  if [ -f /etc/debian_version ]; then
    return 0
  fi

  # If neither check passed
  return 1
}

Copy link
Collaborator

@HumairAK HumairAK Feb 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't be installing system wide packages in e2e makefile targets, pip install is fine since it's scoped to venv, but apt-get installs it in the user's OS. We want this to be an active action, and not a passive one. I'm fine with providing a make target like "install-preq-requisites" and have this be a separate step before invoking the rest of the test suite, but not as part of a full e2e single command.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, one of the issue's acceptance criteria is exactly that:

  • make commands for running tests should not install any tools. In case of having a tool as a pre-requirement, we can have a specific make command for that.

It's what @chahatsagarmain did here if I'm not mistaken.

Comment on lines +32 to +33
python3 -m venv .venv && \
source .venv/bin/activate
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

various tests are installing a virtual environment with python packages in the user environment via pip,
what is the behavior if they re-run the tests?

it would be good if tests re-run dont' have to always re-install the packages and re-use the env, we should also document that some of the make commands will install a venv and packages

I'm thinking it would be good to have clean up commands in those scenarios but because there are so many different tests each with unique cases, I'm not sure how feasible that would be

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

various tests are installing a virtual environment with python packages in the user environment via pip,
what is the behavior if they re-run the tests?

it would be good if tests re-run dont' have to always re-install the packages and re-use the env, we should also document that some of the make commands will install a venv and packages

I think that the installation of packages should be in the setup make commands.

I'm thinking it would be good to have clean up commands in those scenarios but because there are so many different tests each with unique cases, I'm not sure how feasible that would be

As we have setup make commands, we could also have tear-down commands. In that case, we could print a message at the end of the test run warning contributors that they need to run the tear-down command.
How about adding it in a follow-up PR/issue? This is a big PR and we'll likely have other improvements in the CI in the next few days. Rebasing this PR makes the review difficult/error-prone.

python3 -m pip install api/v2alpha1/python && \
pip install components/google-cloud && \
pip install $(shell grep 'pytest==' sdk/python/requirements-dev.txt) && \
pytest ./test/gcpc-tests/run_all_gcpc_modules.py
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like it shouldn't be here, as it's only a setup target and the same command is ran in test-grpc-modulestest-grpc-modules

pytest ./test/gcpc-tests/run_all_gcpc_modules.py

.PHONY: setup-kfp-kubernetes-execution-tests
setup-kfp-kubernetes-execution-tests:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this used in any github action, was there a reason for this?

- name: Install requirements
run: pip install -r ./test/sdk-execution-tests/requirements.txt
run: make setup-sdk-execution
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like we are deploying KFP twice [1], [2] ?

Copy link

New changes are detected. LGTM label has been removed.

parent 7bb0c44
author chahatsagarmain <chahatsagar2003@gmail.com> 1740067717 +0530
committer chahatsagarmain <chahatsagar2003@gmail.com> 1740068190 +0530

parent 7bb0c44
author chahatsagarmain <chahatsagar2003@gmail.com> 1740067717 +0530
committer chahatsagarmain <chahatsagar2003@gmail.com> 1740068098 +0530

make commands for local testing and ci refactor

Signed-off-by: chahatsagarmain <chahatsagar2003@gmail.com>

chore: use local proto go packages for ci (kubeflow#11629)

Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>

fix(backend): upgrade go version to 1.22.12 to fix CVE-2024-45336 (kubeflow#11631)

Signed-off-by: Daniel Dowler <12484302+dandawg@users.noreply.github.com>

fix(backend) fix run retry for argo (kubeflow#11585)

Signed-off-by: arpechenin <arpechenin@avito.ru>

fix(frontend): restrict file explorer to show only .yaml, .yml, .zip, and .tar.gz files (kubeflow#11623)

* fix(frontend): restrict file explorer to show only .yaml, .yml, .zip, and .tar.gz files

Signed-off-by: muzzlol <muzxmmilkhxn@gmail.com>

* test(frontend): update NewPipelineVersion snapshot for file filters

Signed-off-by: muzzlol <muzxmmilkhxn@gmail.com>

---------

Signed-off-by: muzzlol <muzxmmilkhxn@gmail.com>

fix(backend): fixes DAG status update to reflect completion of all tasks (kubeflow#11651)

Signed-off-by: VaniHaripriya <vmudadla@redhat.com>

chore(test): Increased timeout in test (kubeflow#11658)

Signed-off-by: Helber Belmiro <helber.belmiro@gmail.com>

make commands to test locally and ci refactor

Signed-off-by: chahatsagarmain <chahatsagar2003@gmail.com>

add missing step

Signed-off-by: chahatsagarmain <chahatsagar2003@gmail.com>

reviewed changes

Signed-off-by: chahatsagarmain <chahatsagar2003@gmail.com>

fix eol

Signed-off-by: chahatsagarmain <chahatsagar2003@gmail.com>
@hbelmiro
Copy link
Contributor

@HumairAK @chahatsagarmain
This is a big PR that moves code around. I think it's dangerous to leave it open for too much time. I'm afraid that we may miss some commits to the master branch while rebasing this PR.
How about breaking it in several easy-to-review/merge PRs? We could turn #11494 into an epic and have one new issue for each workflow.

@hbelmiro
Copy link
Contributor

/close

We'll proceed with individual PRs for each workflow.

Copy link

@hbelmiro: Closed this PR.

In response to this:

/close

We'll proceed with individual PRs for each workflow.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@google-oss-prow google-oss-prow bot closed this Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants