Bug: uptest e2e generates incorrect script for scaling deployments for import test

[santhoshct]

What happened?

When running an end-to-end test with uptest e2e that involves an import step (02-import.yaml), the tool generates a script with an incorrect kubectl command, causing the test to fail.

The failure occurs during the "Remove State" step, which is intended to scale down Crossplane and provider deployments before proceeding with the import test.

uptest version: v1.4.0

Steps to Reproduce

1. Create a test case that utilizes the uptest e2e command and implicitly generates an import test step.
2. Run the test.
3. The test will fail during the execution of the generated 02-import.yaml file.

Alternatively, you can inspect the generated files without running the test:

uptest e2e <your-test-file>.yaml --render-only

Check the contents of the generated /tmp/uptest-e2e/case/02-import.yaml file.

Error

The following error is observed in the test logs:

error: required flag(s) "replicas" not set
Error: flags cannot be placed before plugin name: -n

Problematic Code

The error is caused by this command within the generated script section for the "Remove State" step:

${KUBECTL} -n ${CROSSPLANE_NAMESPACE} get deploy --no-headers -o custom-columns=":metadata.name" | grep "provider-" | xargs ${KUBECTL} -n ${CROSSPLANE_NAMESPACE} scale deploy --replicas=0

The issue is with how xargs passes arguments to kubectl scale.

Suggested Fix

A more robust way to write this command is to use xargs -I {}, which correctly handles passing each deployment name to kubectl:

${KUBECTL} -n ${CROSSPLANE_NAMESPACE} get deploy --no-headers -o custom-columns=":metadata.name" | grep "provider-" | xargs -I {} ${KUBECTL} -n ${CROSSPLANE_NAMESPACE} scale deploy {} --replicas=0

This ensures kubectl receives the deployment name before the flags.

What environment did it happen in?

• Uptest Version: 1.4.0

[sergenyalcin]

@santhoshct thank you for reporting this. We changed the deployment scale-up/down method with v2.0.0 version of uptest. Now we are using DeploymentRuntimeConfig resources for this. By the way, we still use xargs to achieve this. If you think this issue still persists, please ping us, we can improve here.