19 Comments

Thanks for this. Nice to clean up the home page, hadn't realized I could. I'm curious how you got a specific logo to appear on the documentation home page.

Expand full comment

Thanks! To use your own logo you need:

1. inside of the project create a directory called /assests and put there your logo

2. register assets path in dbt_project.yml, read here https://docs.getdbt.com/reference/project-configs/asset-paths

3. use your logo in markdown like:

![Logo](./assets/logo.png)

I'll make another post and show this example step-by-step!

Expand full comment

Thanks. This is very helpful.

Expand full comment

This may be related to Artur's question - but I've seen multiple references in the docs + other articles about using the +docs config to hide packages from the project's documentation. I've tried the format you suggested along with the docs and have not been able to get it to work.

By default, my dbt_packages directory is in the outer most directory of my project, so I'm not sure if I need to move that to be under my "models" directory to get the above config to work? Any suggestions?

Expand full comment

Actually, dbt_project.yml doesn't support "docs" parameter, that's why it never worked for you (https://docs.getdbt.com/reference/dbt_project.yml).

Also, placement of dbt_packages directory doesn't affect dbt docs. Because at the compilation time, dbt put all the knowledge about your packages to manifest.json. That's where you can actually amend this behaviour. Read my latest dbtips digest #1, I describer there how to hide packages with python.

Expand full comment

dbt_project.yml absolutely does support the "docs" config, as that's how we are setting node colours. However we have found the same as Dylan, that the "show" parameter does not seem to work for packages.

Expand full comment

It’s a “docs” config of “models” parameter, not a root-level config.

Expand full comment

The example you show in this post, while similar to the one in dbt documentation, does not work as far as I can tell. Even though dbt documentation says this hides packages I don't think it actually works in practice. If you've found different I'd be keen to see how you did it.

Expand full comment

It actually works, but only for models. If the package contains macros, they are still visible. To work this around, read my latest post of dbt digest, there is a solution for that

Expand full comment

I see, so it only hides models from packages, not the entire package?

Expand full comment

Thanks for the quick replay @Oleg! I'll check out your other dbt tips and see if that will work for our use case. Appreciate the help!

Expand full comment

Great article, thank you! Could you please elaborate on how you managed to hide macros from dbt_utils? Looks like it is still an issue: https://github.com/dbt-labs/dbt-core/issues/8061

Expand full comment

Yes, there is no standard way yet. But you can manually modify `manifest.json` to exclude unnecessary stuff.

For example, here is a script that reads the manifest, disable dbt_utils macros and persist changes: https://gist.github.com/oleg-agapov/80ebcd8cdee4397d1d7df4f291c109ae

Expand full comment

Got it, thanks!

Expand full comment

Can you tell me if the method for replacing the main page with homepage.md works only for the cloud version, or also for the open-source version? I have version 1.3.1 open-source and for some reason, my main page won't change.

Expand full comment

It works for both versions. Check the documentation for __overview__ macro, maybe you missed something

Expand full comment

Do you recommend creating yml files for each model e.g. dim_users.yml, etc. or a single yml for all models under the folder?

Expand full comment

No hard preferences actually. But here is my workflow: I usually start with one yml file per folder, and once it become big - split into separate models. Also, I usually prepend separate model yamls with underscore, so all documentation is nearly sorted at the top of a directory.

Expand full comment