BDD DSL: Express task lifecycle operations and remove smoke script

[sbaum1994]

Description

The local and EKS NVIDIA Cloud Tasks (NVCT) scenarios call run-nvct-task-smoke.sh. The script hides task API-key generation, task inputs, creation, status polling, and cleanup. The EKS feature also exposes script-specific endpoint and state-path environment variables.

Replace the script with readable steps for individual nvcf-cli task operations. Keep task inputs, CLI options, compute selection, runtime limits, container environment, expected status, timeout, polling, and deletion visible. Reuse the CLI-config step and command builder delivered by #1106 and #1114.

Parent: #858

Completed prerequisite: #1106 through #1114

Live validation prerequisites: #1100 and #1099

Governing contract

Task lifecycle steps are transparent command adapters. They may validate only Gherkin structure. They pass every supplied argument, including empty, repeated, or product-invalid values, unchanged to nvcf-cli; do not maintain task identity, apply defaults, parse or normalize product values, or enforce product preconditions; and preserve the real command result.

As a deliberate readability exception, lifecycle steps whose wording includes successfully assert that the CLI command exits with code 0. Negative and exit-code-specific scenarios continue to use When I run command plus explicit outcome assertions. nvcf-cli and the NVCT API own all product validation.

The status assertion is a bounded test-runner operation because nvcf-cli does not provide a task wait command. It repeats task get --json and compares .task.status with the exact expected string. It must not allowlist status values, classify terminal states, or duplicate NVCT transition rules.

The implementing PR must repeat this governing contract in its description so reviewers can verify the separation-of-concerns boundary.

Proposed DSL

Local multi-cluster example:

Given I use NVCF CLI config "${REPO_ROOT}/tests/bdd/fixtures/nvcf-cli-local.yaml"

When I successfully generate a task API key with CLI options:
  | option        | value                                    |
  | --description | bdd-nvct-task-smoke                      |
  | --scopes      | launch_task,task_details,delete_task     |

And I successfully create task "bdd-nvct-task-smoke" from image "nvcr.io/${SAMPLE_NGC_ORG}/${SAMPLE_NGC_TEAM}/task-simple-sample:local" with CLI options:
  | option              | value                                       |
  | --gpu               | H100                                        |
  | --instance-type     | NCP.GPU.H100_8x                             |
  | --backend           | ncp-local-compute-1                         |
  | --result-strategy   | NONE                                        |
  | --max-runtime       | PT10M                                       |
  | --max-queued        | PT10M                                       |
  | --termination-grace | PT1M                                        |
  | --container-env     | NUM_OF_RESULTS=1                            |
  | --container-env     | DELAY_BETWEEN_RESULTS_IN_MINUTES=0          |
  | --container-env     | FILE_SIZE_BYTES=8192                        |
  | --container-env     | INCLUDE_METADATA=false                      |

Then the task selected by NVCF CLI should reach status "COMPLETED" within "900" seconds, polling every "10" seconds

And I successfully delete the task selected by NVCF CLI

The EKS scenario uses the same steps and only changes visible environment-specific values:

Given I use NVCF CLI config "${REPO_ROOT}/tests/bdd/out/nvcf-cli-eks-bdd-multi.yaml"

When I successfully generate a task API key with CLI options:
  | option        | value                                    |
  | --description | bdd-nvct-task-smoke                      |
  | --scopes      | launch_task,task_details,delete_task     |

And I successfully create task "bdd-nvct-task-smoke" from image "nvcr.io/${SAMPLE_NGC_ORG}/${SAMPLE_NGC_TEAM}/task-simple-sample:local" with CLI options:
  | option              | value                       |
  | --gpu               | H100                        |
  | --instance-type     | NCP.GPU.H100_8x             |
  | --backend           | ${EKS_COMPUTE_CLUSTER_NAME} |
  | --result-strategy   | NONE                        |
  | --max-runtime       | PT10M                       |
  | --max-queued        | PT10M                       |
  | --termination-grace | PT1M                        |
  | --container-env     | NUM_OF_RESULTS=1            |
  | --container-env     | DELAY_BETWEEN_RESULTS_IN_MINUTES=0 |
  | --container-env     | FILE_SIZE_BYTES=8192        |
  | --container-env     | INCLUDE_METADATA=false      |

Then the task selected by NVCF CLI should reach status "COMPLETED" within "900" seconds, polling every "10" seconds

And I successfully delete the task selected by NVCF CLI

Exact step contracts

Common command-adapter behavior

• Interpolate values through the existing ${VAR} helper.
• Safely quote each argument without changing the value received by nvcf-cli.
• Use the config selected by Given I use NVCF CLI config {string}.
• Capture the standard command result and logs.
• Require exit code 0 only when the step wording includes successfully.
• Do not inspect, parse, or validate task product values before execution.
• Do not store task name or ID in BDD scenario state. Let the CLI own its selected-task state.

CLI option tables

• Require only the two-column option | value Gherkin structure and at least one data row.
• Treat every row as two CLI arguments in its original order.
• Preserve repeated options and empty values. Do not deduplicate rows.
• Do not allowlist or denylist option names. Let the CLI reject unknown or unsupported options.
• Do not validate required options, enums, durations, ranges, compatibility, environment syntax, or value syntax.
• Feature authors must not place secret values in visible option tables because command arguments are logged. Do not enforce that policy with a DSL option denylist.

Given I use NVCF CLI config {string}

• Reuse the step delivered by test(bdd): add function lifecycle command adapters #1114.
• Interpolate and store the supplied config argument without resolving, canonicalizing, or checking the path.
• Never fall back to an ambient or default CLI config.

When I successfully generate a task API key with CLI options:

• Run api-key generate --for task followed by the visible option rows.
• Do not derive a description, add scopes, or apply defaults.
• Do not parse, export, or copy the generated key. Let the CLI save and use its task key.

When I successfully create task {string} from image {string} with CLI options:

• Run task create --name <name> --image <image> followed by the visible option rows.
• Pass the task name, image, option names, and values unchanged after interpolation.
• Do not translate friendly setting names into CLI flags.
• Do not apply task defaults or validate task configuration.
• Let nvcf-cli task create save the current task in CLI state.

Then the task selected by NVCF CLI should reach status {string} within {string} seconds, polling every {string} seconds

• Run task get --json through the selected config on each poll. Let the CLI resolve its selected task.
• Require each task get command to exit with code 0 and read only .task.status from its JSON output.
• Compare the returned status with the exact expected string supplied by Gherkin.
• Do not validate the expected status against a known-status list.
• Do not fail early based on a test-owned list of terminal statuses. NVCT owns status meanings and transitions.
• Treat timeout and poll duration as test-runner controls. Validate only that they are positive values the runner can use to bound and schedule polling.
• On timeout, report the expected status, last observed status, timeout, and command-log location. Do not print API keys, secret values, or the full task response.

And I successfully delete the task selected by NVCF CLI

• Run task delete through the selected config and require exit code 0.
• Let the CLI resolve or reject its selected task.
• Keep deletion visible. Do not move it into a hidden hook or composite lifecycle step.

CLI configuration changes

• Add base_nvct_url and nvct_host to the local NVCF CLI fixture so task commands route through tasks.localhost.
• Add base_nvct_url and nvct_host to the generated EKS CLI config. Preserve its existing gateway and Host-header behavior.
• Continue using the existing API Keys URL and Host settings for task-key generation.
• Keep CLI state paths derived from the selected config.
• Remove feature-level NVCT_BDD_* endpoint, state-path, backend, and timeout plumbing.

Smoke script removal

• Migrate every use of tests/bdd/scripts/run-nvct-task-smoke.sh to the steps above.
• Delete the script after local and EKS wiring tests use the new DSL.
• Remove obsolete NVCT_BDD_* documentation, fixture tests, canned runner entries, and script-specific assertions.
• Do not replace the script with another composite helper that hides authorization, creation, polling, and deletion.

Migration scope

• Migrate the local multi-cluster NVCT scenario.
• Migrate the multi-cluster EKS NVCT scenario without changing its gateway target or compute backend.
• Preserve the current image, task request values, expected status, timeout, polling interval, and backend-health prerequisites.
• Keep negative and exit-code-specific CLI or API scenarios on raw command steps.
• Do not add task cancellation, event, result, Helm-task, or secret-management scenarios in this issue.

Definition of Done

• Repeat the governing contract in the implementing PR description.
• Add the exact steps above to tests/bdd/PLAN.md before migrating features.
• Reuse the CLI-config scenario state and generic argument builder from test(bdd): add function lifecycle command adapters #1114.
• Keep command handlers limited to fixed command selection, argument assembly, command execution, exit-zero assertion, and result capture.
• Keep status polling limited to task get --json, exact status comparison, and bounded test-runner timing. Do not add NVCT status semantics.
• Add focused tests for interpolation, quoting, table shape, row ordering, repeated options, empty values, unknown options reaching the runner, product-invalid values reaching the runner, CLI-owned task state, exit-zero assertions, exact status matching, polling timeout, and secret-safe errors.
• Update local and EKS feature wiring tests.
• Remove the smoke script and every obsolete NVCT_BDD_* reference.
• Pass go test -short ./... and lint under tests/bdd.
• Pass the impacted local multi-cluster live feature after fix(nvct-api): consume corrected task scheduling release #1100 and fix(cassandra): support current NVCT task schema #1099 are available on the test branch.
• Record EKS live validation under BDD DSL: Validate second-wave changes on live EKS #1087 when an EKS test cluster is available.

Resources

• Parent epic: Improve BDD feature readability with a common operations DSL #858
• Function lifecycle contract and DSL: BDD DSL: Express function lifecycle operations #1106 and test(bdd): add function lifecycle command adapters #1114
• Corrected NVCT self-managed release: fix(nvct-api): consume corrected task scheduling release #1100
• Cassandra compatibility fix: fix(cassandra): support current NVCT task schema #1099 and Self-managed Cassandra blocks current NVCT task creation #1098
• EKS validation task: BDD DSL: Validate second-wave changes on live EKS #1087

---

By submitting this issue, you acknowledge that you are an assigned member of the NVCF development team and agree to follow our code of conduct and our contributing guidelines.