You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, when deploying a given project in Brickflow, it bundles and deploys all workflows under the project. Ideally, for versioned individual workflows we'd like to have the option to deploy just 1 workflow at a time. Ex.
brickflow projects deploy --project Project1 -e local deploys workflow_a and workflow_b, a nice addition would be to have the option to only deploy workflow_a or workflow_b.
Describe the solution you'd like
brickflow projects deploy --project Project1 --workflow workflow_a -e local with --workflow as optional
Where the bundled path could then possibly include the workflow name
...user/project/workflow/env
Describe alternatives you've considered
The alternative is creating a new project per workflow. In our case where we want a ETL pipeline's stages very carefully bundled, versioned, and released this yields 3 new projects at minimum per pipeline (with 3+ pipelines this yields 9+ minimum total projects increasing codebase size & complexity).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, when deploying a given project in Brickflow, it bundles and deploys all workflows under the project. Ideally, for versioned individual workflows we'd like to have the option to deploy just 1 workflow at a time. Ex.
brickflow projects deploy --project Project1 -e local
deploysworkflow_a
andworkflow_b
, a nice addition would be to have the option to only deployworkflow_a
orworkflow_b
.Describe the solution you'd like
brickflow projects deploy --project Project1 --workflow workflow_a -e local
with--workflow
as optionalWhere the bundled path could then possibly include the workflow name
...user/project/workflow/env
Describe alternatives you've considered
The alternative is creating a new project per workflow. In our case where we want a ETL pipeline's stages very carefully bundled, versioned, and released this yields 3 new projects at minimum per pipeline (with 3+ pipelines this yields 9+ minimum total projects increasing codebase size & complexity).
The text was updated successfully, but these errors were encountered: