docs: fix jekyll build

docs/markdown/20-project-structure/30-profiles.md

@@ -1,24 +1,29 @@
 <!-- .slide -->
+
 # Profiles
 
 Profiles are a centralized way to store configuration that defines connection details for different databases or data warehouses.
 
 Profiles tell _dbt_ **HOW** to run.
 
 _dbt_ searches for a `profile.yml` file in this order:
-* in the main _dbt_ project directory 
-* in the `$HOME/.dbt` directory 
-* path passed as argument of the dbt commands
+
+- in the main _dbt_ project directory
+- in the `$HOME/.dbt` directory
+- path passed as argument of the dbt commands
 
 Profiles make it easier to switch between different environments and databases.
 
 Notes:
-* Profile file are yaml files
-* You can have as many profiles as you want in a file, or use different files (use arguments to define which file to use)
-* Profiles enhance the flexibility and portability of your dbt projects
+
+- Profile file are yaml files
+- You can have as many profiles as you want in a file, or use different files (use arguments to define which file to use)
+- Profiles enhance the flexibility and portability of your dbt projects
 
 ##==##
+
 <!-- .slide: class="with-code"-->
+
 # Profiles
 
 ## Sample `profile.yml` (1/3)
@@ -34,13 +39,17 @@ config:
 ```
 
 ##==##
+
 <!-- .slide: class="with-code"-->
+
 # Profiles
 
 ## Sample `profile.yml` (2/3)
 
 You can use anchors in `YAML` to avoid repeating configuration blocks.
 
+<!-- {% raw %} -->
+
 ```yaml[]
 # Configuration for all authentication methods
 config_global: &config_global
@@ -59,8 +68,12 @@ config_service_account: &config_service_account
   keyfile: "{{ env_var('GOOGLE_APPLICATION_CREDENTIALS') }}"
 ```
 
+<!-- {% endraw %} -->
+
 ##==##
+
 <!-- .slide: class="with-code"-->
+
 # Profiles
 
 ## Sample `profile.yml` (3/3)
@@ -83,12 +96,15 @@ local:
 ```
 
 ##==##
+
 <!-- .slide: class="with-code"-->
+
 # Using profiles
 
 Default profile name must be set in `dbt_project.yml` file.
 
 `dbt_project.yml`
+
 ```yaml[]
 ...
 name: "sfeir_school_dbt"
@@ -112,4 +128,5 @@ $ dbt run --profile gitlab --profiles-dir ~/.dbt/profiles/school.yml
 ```
 
 Notes:
-* dbt does NOT use "default" profile anymore to avoid unintentionnal usage of credentials / env. 
+
+- dbt does NOT use "default" profile anymore to avoid unintentionnal usage of credentials / env.

docs/markdown/30-models/10-what-is-a-model.md

@@ -1,33 +1,40 @@
 <!-- .slide -->
+
 # What is a model?
 
 A _dbt_ model is a `SELECT` statement, written in a `.sql` file.
 
-* Each SQL file contains only one model
-* File name determine the model name
-* Models must be defined in directory `models` and its subdirectories
+- Each SQL file contains only one model
+- File name determine the model name
+- Models must be defined in directory `models` and its subdirectories
 
 <br/><br/>
 During the execution of `dbt run`, `SELECT` requests are wrapped in `CREATE VIEW` or `CREATE TABLE` statements.
+
 <!-- .element: class="fragment" -->
 
 Notes:
+
 - There can be more than 1 SELECT statement in each model
 - Starting with dbt Core 1.3, it's possible to define models using Python files
 - There can't be 2 models with the same name !
 
 ##==##
+
 <!-- .slide: class="with-code"-->
+
 # Sample model
 
 The model `models/staging/customers.sql`
+
 ```sql
 SELECT
   id
   , area
   , CONCAT(firstname, ' ', UPPER(lastname)) AS `name`
 FROM customers
 ```
+
 <br/>
 <div>
 will produce the following query:
@@ -41,30 +48,34 @@ CREATE VIEW dbt_school.customers AS (
   FROM customers
 )
 ```
+
 </div>
 <!-- .element: class="fragment" -->
 
 Notes:
+
 - No ";" at the end of the model, or it will generate an error
 
 ##==##
+
 <!-- .slide -->
+
 # Model configuration
 
 By default, _dbt_ will create models:
 
-* Using views and not tables
-* In the default schema defined in the `dbt_project.yml` file
-* Using the `.sql` file name
+- Using views and not tables
+- In the default schema defined in the `dbt_project.yml` file
+- Using the `.sql` file name
 
 <br/>
 <br/>
 
 <div>
 But it's possible to change this default behavior: <br/>
 
-* In the `dbt_project.yml` configuration file
-* Directly in models using `config` blocks
+- In the `dbt_project.yml` configuration file
+- Directly in models using `config` blocks
 
 <br/>
 
@@ -74,10 +85,15 @@ But it's possible to change this default behavior: <br/>
 <!-- .element: class="fragment" -->
 
 ##==##
+
 <!-- .slide: class="with-code"-->
+
 # Sample direct configuration
 
+<!-- {% raw %} -->
+
 `models/staging/customers.sql`
+
 ```sql[6-11|1-4]
 {{ config(
     materialized="table",
@@ -92,8 +108,12 @@ FROM
     customers
 ```
 
+<!-- {% endraw %} -->
+
 ##==##
+
 <!-- .slide: class="with-code"-->
+
 # `dbt_project.yml` model configuration
 
 ```yaml[|6-7|8-9]

docs/markdown/30-models/40-tags.md

@@ -1,4 +1,5 @@
 <!-- .slide -->
+
 # Tagging your ressources
 
 _dbt_ includes the option to tag your models to regroup/filter them.
@@ -7,9 +8,9 @@ _dbt_ includes the option to tag your models to regroup/filter them.
 <div>
 _tags_ can be defined in:<br/> <br/>
 
-* your `dbt_project.yml` file
-* models property file
-* models configuration blocks
+- your `dbt_project.yml` file
+- models property file
+- models configuration blocks
 </div>
 <!-- .element: class="fragment" -->
 
@@ -18,18 +19,22 @@ _tags_ can be defined in:<br/> <br/>
 _tags_ accumulate hierarchically:
 
 ![center hm-200](./assets/images/docs/markdown/20-project-structure/dbt_configuration_directives.svg)
+
 </div>
 <!-- .element: class="fragment" -->
 
 Notes:
+
 - Tags are not labels in BigQuery -- there is special syntax (dict) in config blocks for that
 
 ##==##
+
 <!-- .slide: class="with-code"-->
 
 # Tagging example
 
 `dbt_project.yml`
+
 ```yaml[]
 ...
 models:
@@ -42,21 +47,29 @@ models:
         - "intermediate-models"
 ```
 
+<!-- {% raw %} -->
 
 `models/staging/__models.yml`
+
 ```yaml[]
 models:
   - name: customers
     config: # Don't forget the "config" block
       tags: ["staging", "dimensions"]
 ```
 
+<!-- {% endraw %} -->
+
 ##==##
+
 <!-- .slide: class="with-code"-->
 
 # Tagging example
 
 `models/staging/customers.sql`
+
+<!-- {% raw %} -->
+
 ```sql[4]
 {{ config(
     materialized="table",
@@ -72,3 +85,4 @@ FROM
     customers
 ```
 
+<!-- {% endraw %} -->

docs/markdown/40-source-and-ref/10-ref.md

@@ -1,4 +1,5 @@
 <!-- .slide -->
+
 # The `ref()` macro
 
 References are how _dbt_ handle dependencies between models and build the DAG at runtime.
@@ -8,13 +9,17 @@ It's handled by _dbt_ with the `ref()` function, and it should be the only way f
 Seeds can be referenced directly with `ref()` using the seed name.
 
 Notes:
-* If you don't use the ref() macro, then you're doing it wrong.
+
+- If you don't use the ref() macro, then you're doing it wrong.
 
 ##==##
+
 <!-- .slide: class="with-code"-->
+
 # Using the `ref()` macro
 
 `/models/companies.sql`
+
 ```sql
 SELECT company_id
      , company_name
@@ -25,13 +30,19 @@ WHERE enabled = 1
 
 <br/>
 
+<!-- {% raw %} -->
+
 `/models/customers.sql`
+
 ```sql[|2]
 SELECT *
 FROM {{ ref('companies') }}
 WHERE is_customer = 1
 ```
 
+<!-- {% endraw %} -->
+
 Notes:
-* DAG = Directed Acyclic Graph
-* There is a 2 arguments version of ref(), with the package name as first argument
+
+- DAG = Directed Acyclic Graph
+- There is a 2 arguments version of ref(), with the package name as first argument