pull command is a utility for getting resource configuration files from the web UI to a local workspace. You can use it to migrate resources to a code-based workflow. If you already have local files that correspond with Hashboard resources,
hb pull will update the local versions of those files.
The default behavior of
pull is to only update resources that were created through the Hashboard CLI (i.e. any
For example: let's say you originally built four models with the CLI and another two models in the UI. If you run
hb pull from an empty directory, you'll only pull those four model files. You won't get the two UI-built models, or any additional resources built in the UI for that matter.
You can also pull resources that were not built with the CLI. If you want to pull down a resource that was built in the UI, you have two options:
You can use the
--all flag to get every single Hashboard resource regardless of whether it was created with the CLI.
hb pull --all
You can pull down a specific resource by its Global Resource Name.
When developing locally, you are not required to specify GRNs in Hashboard
resource configuration files. However, when running
hb deploy, GRNs are
assigned based on the relative path from the working directory to the resource
configuration file. Subsequent uses of
hb pull should therefore be run from
the same working directory.
# pull by a specific grn hb pull m:s3AdinvBhsdJ: # alternatively, pull by alias hb pull m::my_sales_model
The behavior of
hb pull is a bit different when used for dbt models. We cannot update models automatically inside of dbt files (since there could be jinja that we can't decompile).
Instead of updating resources in place, we'll create new model files outside of your dbt project. This lets you inspect the configuration and merge it into your dbt files.
hb pull uses the most verbose (and specific) possible format of a resource. Some configuration that is just defaulted or configured by Hashboard will be exported.
For example: if you export a resource, it will default to being exported with a
pinned GRN. You can remove the GRN to enable deploying the resource across different projects (or use an alias so that the resource is not bound to a specific instance in a single project).