Merge branch 'current' into joellabes-patch-1

.github/lychee.toml

@@ -0,0 +1,54 @@
+###
+### Display
+###
+
+# Verbose program output
+# Accepts log level: "error", "warn", "info", "debug", "trace"
+verbose = "info"
+
+# Don't show interactive progress bar while checking links.
+no_progress = true
+
+###
+### Cache
+###
+
+# Enable link caching. This can be helpful to avoid checking the same links on
+# multiple runs.
+cache = false
+
+###
+### Requests
+###
+
+# Website timeout from connect to response finished.
+timeout = 30
+
+# Comma-separated list of accepted status codes for valid links.
+accept = [200, 403, 429]
+
+# Base URL or website root directory to check relative URLs.
+base = "https://docs.getdbt.com"
+
+###
+### Exclusions
+###
+
+# Exclude URLs from checking (supports regex)
+exclude = [
+  'frontMatter.',
+  'https://badge.fury.io',
+  'https://img.shields.io',
+  'https://gitlab.com',
+  'https://dbtlabs.postman.co',
+  'https://mobile.twitter.com',
+  'https://twitter.com',
+  'https://www.twitter.com',
+]
+
+# Exclude all mail addresses from checking
+exclude_mail = true
+
+# Check links inside `<code>` and `<pre>` blocks as well as Markdown code
+# blocks.
+include_verbatim = false

.github/workflows/links.yml

@@ -0,0 +1,17 @@
+name: Docs Link Checker
+
+on:
+  schedule:
+    # Run every day at 12:00 UTC
+    - cron: '0 12 * * *'
+
+jobs:
+  markdown-link-check:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+      - name: Link Checker
+        uses: lycheeverse/lychee-action@master
+        with:
+          args: --verbose --config .github/lychee.toml './website/**/*.md'

README.md

@@ -56,9 +56,9 @@ You can click a link available in a netlify bot PR comment to see and review you
 2. Clone this repo: `git clone https://github.com/dbt-labs/docs.getdbt.com.git`
 3. `cd` into the repo: `cd docs.getdbt.com`
 4. `cd` into the `website` subdirectory: `cd website`
-5. Install the required node packages: `npm install` (optional — install any updates)
-6. Build the website: `npm start`
-7. Before pushing your changes to a branch, check that all links work by using the `make build` script.
+5. Install the required node packages: `make install` or `npm install` (optional — install any updates)
+6. Build the website: `make run` or `npm start`
+7. Before pushing your changes to a branch, run `make build` or `npm run build` and check that all links work
 
 Advisory:
 - If you run into an `fatal error: 'vips/vips8' file not found` error when you run `npm install`, you may need to run `brew install vips`. Warning: this one will take a while -- go ahead and grab some coffee!

contributing/content-style-guide.md

@@ -16,6 +16,7 @@ This guide includes standards we want to emphasize, likely because we've made de
 * [Oxford comma](#Oxford-comma)
 * [Lists](#Lists)
 * [Tables](#Tables)
+* [Cards](#Cards)
 * [Word choice & terminology](#word-choice--terminology)
 * [Links](#Links)
 * [Images](#Images)
@@ -340,6 +341,76 @@ A table following an H3 heading:
 > | `-readable` | Print output in human readable format. | <ul><li>`true`</li><li>`false`</li></ul> |
 > | `-file` | Print output to file instead of stdout. | Name of the file. |
 
+## Cards
+
+Use the `<Card` component to display content and actions on a single topic. Users should cards easy to scan for relevant and actionable information. Elements, like text, icons, and links can be used inside a card. 
+
+You can configure a card in 2, 3, 4, or 5-column grids. To maintain a good user experience, be mindful of how the cards are displayed. Cards with multiple paragraphs may not work because the text and cards will appear too squished, making them hard to read and a bad user experience. 
+
+There won't be many instances where you need to display 4 or 5 cards on the docs site. While we recommend you use 2 or 3-column grids, you can use 4 or 5-column grids in the following scenarios:
+
+- For cards that contain little text and limited to under 15 words. (This is to make sure the text isn't squished)
+- Always have the `hide_table_of_contents:` frontmatter set to `true` (This hides the right table of contents). 
+
+Otherwise, the text will appear squished and provide users with a bad experience.
+
+- `<divclassName="grid--2-col">`: creates 2 column cards
+- `<divclassName="grid--3-col">`: creates 3 columns cards
+- `<divclassName="grid--4-col">`: creates 4 columns cards (use sparingly)
+- `<divclassName="grid--5-col">`: creates 5 columns cards (use sparingly)
+- You can't create cards with 6 or more columns as that would provide users a poor experience.
+
+Refer to [dbt Cloud features](/docs/cloud/about-cloud/dbt-cloud-features) and [Quickstarts](/docs/quickstarts/overview) as examples. 
+
+### Create cards
+
+To create cards in markdown, you need to:
+
+- Start off by using the appropriate `<divclassName="grid--column_num-col">` for your use case 
+- Create a `<Card` component (which is wrapped within the div)
+- Add the props within the card component, including `title`,`body`,`link`,`icon`.
+- Close out the div by using `</div>`
+
+Refer to the following prop list for detailed explanation and examples:
+
+| Prop | Type | Info | Example |
+| ---- | ---- | ---- | ------- |
+| `title` | required | The title should be clear and explain an action the user should take or a product/feature. | `title: dbt Cloud IDE`
+| `body` | required | The body contains the actionable or informative text for the user. You can include `<a href="` link within the body of the text. However, if you do this, you must not include the `link` prop set as that'll override any `<a href's` within the body text.  | `body="The IDE is the easiest and most efficient way to develop dbt models`
+| `link` | optional | Add a link to the entire card component so when users click on the card, it'll trigger the link. Adding a link prop means it'll override any links within the body and if users click on the card, they'll be directed to the link set by the link prop. | `link="/docs/cloud/dbt-cloud-ide/develop-in-the-cloud`
+| `icon` | optional but recommended | You can add an icon to the card comonent by using any icons found in the [icons](https://github.com/dbt-labs/docs.getdbt.com/tree/current/website/static/img/icons) directory. <br /> * Icons are added in .svg format and you must add icons in two locations: website/static/img/icons and website/static/img/icons/white. This is so users can view the icons in dark or light mode on the docs.getdbt.com site. | ` icon="pencil-paper"/>` |
+
+The following is an example of a 4 card column:
+
+```
+<div className="grid--4-col">
+
+<Card
+    title="dbt Cloud IDE" 
+    body="The IDE is the easiest and most efficient way to develop dbt models." 
+    link="/docs/cloud/dbt-cloud-ide/develop-in-the-cloud" 
+    icon="pencil-paper"/> 
+    
+<Card  ## this card component has an <a href link within the body. Notice how there's no link prop set as it'll override any a href's within the body. 
+    title="New title"
+    body="more <a href='www.getdbt.com'>text text</a>"
+    icon="pencil-paper"/>
+
+<Card
+    title="New title"
+    body="more text text"
+    link="/docs/cloud/dbt-cloud-ide/develop-in-the-cloud" 
+    icon="pencil-paper"/>
+
+<Card
+    title="New title"
+    body="more text text"
+    link="/docs/cloud/dbt-cloud-ide/develop-in-the-cloud" 
+    icon="pencil-paper"/>
+
+</div>
+```
+
 ## Word choice & terminology
 Use active voice instead of passive. Active voice is clearer and more direct, making it easier to translate. 
 

contributing/single-sourcing-content.md

@@ -5,7 +5,7 @@
   * [Versioning entire pages](#versioning-entire-pages)
   * [Versioning blocks of content](#versioning-blocks-of-content)
 * [Using global variables](#using-global-variables)
-* [Reusing snippets of content](#reusing-snippets-of-content)
+* [Reusing content](#reusing-content)
 
 ## About versioning
 
@@ -28,13 +28,13 @@ exports.versions = [
 ]
 ```
 
-The **version** property is the value which shows in the nav dropdown. This value is compared to the VersionBlock component on a docs page to determine whether that section should be visible for the current active version (See the **Versioning the Sidebar** section on using the VersionBlock component).
+The **version** property is the value shown in the nav dropdown. This value is compared to the VersionBlock component on a docs page to determine whether that section should be visible for the currently active version (See the **Versioning the Sidebar** section on using the VersionBlock component).
 
 ### Using end-of-life dates
 
 The **EOLDate** property determines when a version is no longer supported. A version is supported up until 1 year after its release.
 
-When a documentation page is viewed, the **EOLDate** property for the active version is compared to today’s date. If the current version has reached, or is nearing the end of support, a banner will show atop the page, notifying the visitor of the end-of-life status.
+When a documentation page is viewed, the **EOLDate** property for the active version is compared to today’s date. If the current version has reached or is nearing the end of support, a banner will show atop the page, notifying the visitor of the end-of-life status.
 
 Two different versions of the banner will show depending on the end-of-life date: 
 
@@ -47,11 +47,11 @@ The content for these two EOLDate banners are located in the `website/src/theme/
 
 ### Versioning entire pages
 
-If a Docs page should not be available for the selected version, it is possible to version the entire page. This is managed in the `versionedPages` array within the `website/dbt-versions.js` file.
+If a Docs page is unavailable for the selected version, it is possible to version the entire page. This is managed in the `versionedPages` array within the `website/dbt-versions.js` file.
 
 Two things occur when a page is not available for the selected version:
 
-- A banner will appear atop the page, noting this page covers a new feature which isn’t available for the selected version.
+- A banner will appear atop the page, noting this page covers a new feature that isn’t available for the selected version.
 - The page is removed from the sidebar
 
 
@@ -70,9 +70,9 @@ exports.versionedPages = [
 
 **page** (mandatory): The path of the Docs page to version. This string must match the string for the page in the `sidebars.js` file.
 
-**firstVersion** (optional): Sets the first version which this page is available.
+**firstVersion** (optional): Sets the first version on which this page is available.
 
-**lastVersion** (optional): Sets the last version which this page is available.
+**lastVersion** (optional): Sets the last version on which this page is available.
 
 ## Versioning blocks of content
 
@@ -143,7 +143,7 @@ Using a global variable requires two steps:
 2. Use the **Var** component to add the global variable to a page.
 
 ```jsx
-// The dbtCore property is the identifer for the variable,
+// The dbtCore property is the identifier for the variable,
 // while the name property is the value shown on the page.
 
 exports.dbtVariables = {
@@ -219,22 +219,102 @@ To use the component at the beginning of a sentence, add a non-breaking space ch
 <Var name="dbt" /> is awesome!
 ```
 
-## Reusing snippets of content
+## Reusing content
 
-The Snippet component allows for content to be reusable throughout the Docs. This is very similar to the existing FAQ component.
+To reuse content on different pages, you can use some techniques like partial files or snippets. Partial files, a built-in Docusaurus feature, is the recommended method over snippets.
+
+### Partial file
+
+A partial file allows you to reuse content throughout the docs. Here are the steps you can take to create and use a partial file:
+
+1. Create a new markdown partial file in the `website/snippets` directory. The file name must begin with an underscore, like `_filename.md`
+2. Go back to the docs file that will pull content from the partial file.
+3. Add the following import file: `import ComponentName from '/snippets/_this-is-your-partial-file-name.md';`
+   * You must always add an import file in that format. Note you can name `ComponentName` (a partial component) can be whatever makes sense for your purpose.
+   * `.md` needs to be added to the end of the filename. 
+4. To use the partial component, go to the next line and add `<ComponentName />`. This fetches the reusable content in the partial file
+   * Note `anyname` can be whatever makes sense for your purpose.
+
+You can also use this for more advanced use cases like reusable frontmatter.
+
+#### Partial example
+
+1. To create a new partial to use throughout the site, first, we will create a new markdown partial file within the snippets directory:
+
+```markdown
+/snippets/_partial-name.md
+```
+
+2. Add the following reusable content in the `/snippets/_partial-name.md` partial file:
+
+```markdown
+## Header 2
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam fermentum porttitor dui, id scelerisque enim scelerisque at.
+```
+
+3. Now, go back to the docs file and add the following code to fetch the reusable content added in the partial file:
+
+```markdown
+Docs content here.
+
+`import SetUpPages from '/snippets/_partial-name.md';`
+
+<SetUpPages />        					
+
+Docs content here.
+```
+
+- `import SetUpPages from '/snippets/_partial-name.md';`  &mdash; A partial file that will be imported by other files
+- `<SetUpPages />` &mdash;  A component that imports content from the partial file. You can also use it to pass in data into the partial using props (See 'How to use props to pass different content on multiple pages?' below). 
+
+4. This will then render the content of the docs in the partial file.
+
+
+<br />
+
+
+<details>
+<summary><b>How to use props to pass different content on multiple pages?</b></summary><br />
+
+You can add props on the component only if you want to pass in data from the component into the partial file. This is useful for using the same partial component on
+multiple docs pages and displaying different values for each. For example, if we wanted to use a partial on multiple pages and pass in a different 'feature' for each
+docs page, you can write it as:
+
+```
+import SetUpPages from '/snippets/_available-enterprise-only.md';
+
+`<SetUpPages feature='A really cool feature' /> 
+```
+
+Then in the `/snippets/_available-enterprise-only.md file`, you can display that feature prop with:
+
+>This feature: `{props.feature}` other content etc...
+
+This will then translate to:
+
+>This feature: A really cool feature other content etc...
+
+In this example, the component `<SetUpPages feature='` is passing 'feature' into the partial. This is useful when using dynamic data (for example if you wanted to use the same partial on multiple docs pages, but change the values within the partial for each page)
+
+</details>
+
+### Snippets
+
+The Snippet component allows for content to be reusable throughout the Docs. This is very similar to the existing FAQ component. Using partial files, which is a built-in Docusaurus feature, is recommended over snippets. 
 
 Creating and using a snippet requires two steps:
 
 1. Create a new markdown snippet file in the `website/snippets` directory.
-2. Use the `<Snippet src="filename" />` component within a Docs file.
+2. Use the `<Snippet path="filename" />` component within a Docs file.
 
-### Snippet properties
+#### Snippet properties
 
 **src:** Expects the file name of the snippet which lives in the snippets directory
 
-### Snippet example
+#### Snippet example
 
-To create a new snippet to use throughout the site, first we will create a new markdown snippet within the snippets directory:
+To create a new snippet to use throughout the site, first, we will create a new markdown snippet within the snippets directory:
 
 ```markdown
 ## Header 2
@@ -247,7 +327,7 @@ Now, we can add this snippet to a Docs file with the Snippet component:
 ```markdown
 Docs content here.
 
-<Snippet src="lorem-ipsum" />
+<Snippet path="lorem-ipsum" />
 
 Docs content here.
 ```

website/Makefile

@@ -0,0 +1,10 @@
+.PHONY: run install build
+
+run:
+	npm start
+
+install:
+	npm install
+
+build:
+	DOCS_ENV=build npm run build

website/blog/2021-02-05-dbt-project-checklist.md

@@ -200,7 +200,7 @@ Are you using the IDE and if so, how well?
 
 **Useful links**
 
-*   [dbt Cloud as a CI tool](/docs/deploy/cloud-ci-job)
+*   [dbt Cloud as a CI tool](/docs/deploy/continuous-integration)
 
 
 ## ✅ DAG Auditing

website/blog/2022-05-03-making-dbt-cloud-api-calls-using-dbt-cloud-cli.md

@@ -109,7 +109,7 @@ After the initial release I started to expand to cover the rest of the dbt Cloud
 
 In this example we’ll download a `catalog.json` artifact from the latest run of a dbt Cloud job using `dbt-cloud run list` and `dbt-cloud get-artifact` and then write a simple Data Catalog CLI application using the same tools that are used in `dbt-cloud-cli` (i.e., `click` and `pydantic`). Let’s dive right in!
 
-The first command we need is the `dbt-cloud run list` which uses an [API V4 endpoint](https://docs.getdbt.com/dbt-cloud/api-v4#operation/list-account-runs) that returns runs sorted by creation date, with the most recent run appearing first. The command returns a JSON response that has one top-level attribute `data` that contains a list of runs. We’ll need to extract the `id` attribute of the first one and to do that we use [jq](https://stedolan.github.io/jq/):
+The first command we need is the `dbt-cloud run list` which uses an [API endpoint](https://docs.getdbt.com/dbt-cloud/api-v2-legacy#/operations/List%20Runs) that returns runs sorted by creation date, with the most recent run appearing first. The command returns a JSON response that has one top-level attribute `data` that contains a list of runs. We’ll need to extract the `id` attribute of the first one and to do that we use [jq](https://stedolan.github.io/jq/):
 
 ```
 latest_run_id=$(dbt-cloud run list --job-id $DBT_CLOUD_JOB_ID | jq .data[0].id -r)