Description
Is your feature request related to a problem? Please describe.
Since the Orchestrator API is released, cube.dev allows better integration with workflow-tools like Airflow and Dagster. However, there is a chance to extend the integration options by allowing to control a cube-installation (core and cloud) using a CLI.
Describe the solution you'd like
I feel that Cube could also provide CLI access to runtime functionality. The beauty of a simple "cube" binary/command is that a whole new ecosystem of scripting outside of Airflow/Prefect/Dagster becomes available.
Running simple commands like
# refresh all pre-aggs in all models (checks refresh-keys)
$> cube run
# refresh all pre-aggs in 'my_model' (checks refresh keys)
$> cube run -m my_model
# refresh all pre-aggs in 'my_model' and pre-agg 'foo' in 'my_model2' (checks refresh keys)
$> cube run -m my_model my_model2.foo
# refresh 3 hourly partitions in pre-agg 'main' in model 'my_model' (checks refresh-keys)
$> cube run -m my_model.main["2023-04-05T04:00:00", "2023-04-06T23:00:00", "2023-04-06T18:00:00"]
# enforce refresh of all pre-aggregations of a (ignoring refresh-key)
$> cube run -m my_model --full-refresh
with some config in ~/.cube/config.yaml for connecting and authenticating to cube-api, would be very great. Exactly mimicking the DBT flow.
Cube Models should also have tags/labels, like in DBT (see https://docs.getdbt.com/reference/resource-configs/tags), to select groups of models to execute.
The cube command would internally call the cube-api to execute the command.
I feel there would be a lot of potential here:
- Getting status of the cube cluster (as text or json or yaml)
- Getting information about models (/meta)
- Getting information about jobs
- ...
Another famous example to compare to is kubectl, which is a great interface to the kubernetes-api.
IMHO that is missing for cube-core to integrate in even more use-cases.
Describe alternatives you've considered
Having the cube-api, an alternative is to develop our own shell-wrapper.