In addition to submitting a one-time job run through the databricks runs submit CLI, it would be great to additionally support an experimental --wait option to await its success (polling job status every ~30s). This would greatly simplify integration testing use cases, allowing us to generalize plugins like https://github.com/databricks/run-notebook across CI/CD providers.
In the future, we might consider:
- Extending this parameter to the
databricks jobs run-now API to allow awaiting the result of a run of an existing job as well
- Making the polling interval configurable, with some fixed minimum to avoid DOSing the jobs
/runs/get REST API endpoint used to poll for run status.
The --wait option suggestion is based off of a similar API change proposed in this PR. This functionality is also similar to that provided by dbx launch --trace, but has the added flexibility of being able to run jobs that are not declared in DBX's YAML format & without requiring the caller to install dbx and invoke dbx configure
In addition to submitting a one-time job run through the
databricks runs submitCLI, it would be great to additionally support an experimental--waitoption to await its success (polling job status every ~30s). This would greatly simplify integration testing use cases, allowing us to generalize plugins like https://github.com/databricks/run-notebook across CI/CD providers.In the future, we might consider:
databricks jobs run-nowAPI to allow awaiting the result of a run of an existing job as well/runs/getREST API endpoint used to poll for run status.The
--waitoption suggestion is based off of a similar API change proposed in this PR. This functionality is also similar to that provided bydbx launch --trace, but has the added flexibility of being able to run jobs that are not declared in DBX's YAML format & without requiring the caller to installdbxand invokedbx configure