Added copy-to-clipboard button to most code snippets (#527)

Author: janet-can

_includes/agent-helm-command.md

@@ -1,3 +1,4 @@
+{% include code-header.html %}
 ```shell
 helm install soda-agent soda-agent/soda-agent \
   --set soda.agent.target=azure-aks-virtualnodes \

_includes/agent-practice-datasource.md

@@ -1,6 +1,7 @@
 If you wish to try creating a new data source in Soda Cloud using the agent you deployed, you can use the following command to create a PostgreSQL warehouse containing example data from the <a href="https://data.cityofnewyork.us/Transportation/Bus-Breakdown-and-Delays/ez4e-fazm" target="_blank">NYC Bus Breakdowns and Delay Dataset</a>.
 
 From the command-line, copy+paste and run the following to create the data source as a pod on your new cluster.
+{% include code-header.html %}
 ```shell
 cat <<EOF | kubectl apply -n soda-agent -f -
 ---
@@ -45,6 +46,7 @@ service/nybusbreakdowns created
 
 <br />
 Once the pod of practice data is running, you can use the following configuration details when you add a data source in Soda Cloud, in [step 2]({% link soda-cloud/add-datasource.md %}#2-connect-the-data-source), **Connect the Data Source**.
+{% include code-header.html %}
 ```yaml 
 data_source your_datasource_name:
   type: postgres

_includes/expect-one-result.md

@@ -1,7 +1,7 @@
 Be aware that a check that contains one or more alert configurations only ever yields a *single* check result; one check yields one check result. If your check triggers both a `warn` and a `fail`, the check result only displays the more severe, failed check result. 
 
 Using the following example, Soda Core, during a scan, discovers that the data in the dataset triggers both alerts, but the check result is still `Only 1 warning`. Nonetheless, the results in the CLI still display both alerts as having both triggered a `warn`.
-
+{% include code-header.html %}
 ```yaml
 checks for dim_employee:
   - schema:
@@ -23,7 +23,7 @@ Sending results to Soda Cloud
 ```
 
 Adding to the example check above, the check in the example below data triggers both `warn` alerts and the `fail` alert, but only returns a single check result, the more severe `Oops! 1 failures.`
-
+{% include code-header.html %}
 ```yaml
 checks for dim_employee:
   - schema:

_includes/foreach-config.md

@@ -4,7 +4,7 @@ Add a **for each** section to your checks YAML file to specify a list of checks
 2. Nested under the section header, add two nested keys, one for `datasets` and one for `checks`. 
 3. Nested under `datasets`, add a list of datasets against which to run the checks. Refer to the example below that illustrates how to use `include` and `exclude` configurations and wildcard characters {% raw %} (%) {% endraw %}.
 4. Nested under `checks`, write the checks you wish to execute against all the datasets listed under `datasets`. 
-
+{% include code-header.html %}
 ```yaml
 for each dataset T:
   datasets:

_includes/in-check-filters.md

@@ -1,7 +1,7 @@
 Add a filter to a check to apply conditions that specify a portion of the data against which Soda executes the check. For example, you may wish to use an in-check filter to support a use case in which "Column X must be filled in for all rows that have value Y in column Z".
 
 Add a filter as a nested key:value pair, as in the following example which filters the check results to display only those rows with a value of 81 or greater and which contain `11` in the `sales_territory_key` column. You cannot use a variable to specify an in-check filter.
-
+{% include code-header.html %}
 ```yaml
 checks for dim_employee:
   - max(vacation_hours) < 80:
@@ -10,7 +10,7 @@ checks for dim_employee:
 ```
 
 You can use `AND` or `OR` to add multiple filter conditions to a filter key:value pair to further refine your results, as in the following example.
-
+{% include code-header.html %}
 ```yaml
 checks for dim_employee:
   - max(vacation_hours) < 80:
@@ -19,7 +19,7 @@ checks for dim_employee:
 ```
 
 To improve the readability of multiple filters in a check, consider adding filters as separate line items, as per the following example.
-
+{% include code-header.html %}
 ```yaml
 checks for dim_employee:
   - max(vacation_hours) < 80:

_includes/test-connection.md

@@ -1,7 +1,7 @@
 ## Test the data source connection
 
 To confirm that you have correctly configured the connection details for the data source(s) in your configuration YAML file, use the `test-connection` command. If you wish, add a `-V` option to the command to returns results in verbose mode in the CLI.
-
+{% include code-header.html %}
 ```shell
 soda test-connection -d my_datasource -c configuration.yml -V
 ```

soda-agent/secrets.md

@@ -31,7 +31,7 @@ OR
 * in a values YAML file which you store locally but reference in the `helm install` command; see below
 
 ### Values YAML file
-
+{% include code-header.html %}
 ```yaml
 soda:
   apikey:
@@ -42,7 +42,7 @@ soda:
 ```
 
 #### helm install command
-
+{% include code-header.html %}
 ```shell
 helm install soda-agent soda-agent/soda-agent \
   --values values.yml \

soda-cl/anomaly-score.md

@@ -12,7 +12,7 @@ redirect_from: /soda-cloud/anomaly-detection.html
 
 Use an anomaly score check to automatically discover anomalies in your time-series data. <br> 
 *Requires Soda Cloud and Soda Core Scientific.*<br />
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
   - anomaly score for row_count < default
@@ -54,7 +54,7 @@ Refer to [Troubleshoot Soda Core Scientific installation](#troubleshoot-soda-cor
 ## Define an anomaly score check
 
 The following example demonstrates how to use the anomaly score for the `row_count` metric in a check. You can use any [numeric]({% link soda-cl/numeric-metrics.md %}), [missing]({% link soda-cl/missing-metrics.md %}), or [validity]({% link soda-cl/validity-metrics.md %}) metric in lieu of `row_count`. 
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
   - anomaly score for row_count < default
@@ -66,13 +66,14 @@ checks for dim_customer:
 <br />
 You can use any [numeric]({% link soda-cl/numeric-metrics.md %}), [missing]({% link soda-cl/missing-metrics.md %}), or [validity]({% link soda-cl/validity-metrics.md %}) metric in anomaly score checks.  The following example detects anomalies for the average of `order_price` in an `orders` dataset.
 
+{% include code-header.html %}
 ```yaml
 checks for orders:
   - anomaly score for avg(order_price) < default
 ```
 
 The following example detects anomalies for the count of missing values in the `id` column. 
-
+{% include code-header.html %}
 ```yaml
 checks for orders:
   - anomaly score for missing_count(id) < default:
@@ -121,14 +122,14 @@ Consider using the Soda Core Python library to set up a [programmatic scan]({% l
 
 
 #### Example with quotes
-
+{% include code-header.html %}
 ```yaml
 checks for "dim_customer":
   - anomaly score for row_count < default
 ```
 
 #### Example with for each
-
+{% include code-header.html %}
 ```yaml
 for each dataset T:
   datasets:

soda-cl/automated-monitoring.md

@@ -11,7 +11,7 @@ parent: SodaCL
 
 Use automated monitoring checks to instruct Soda to automatically check for row count anomalies and schema changes in a dataset.<br />
 *Requires Soda Cloud* 
-
+{% include code-header.html %}
 ```yaml
 automated monitoring:
   datasets:
@@ -100,7 +100,7 @@ Need help? Ask the team in the <a href="https://community.soda.io/slack" target=
 In the context of [SodaCL check types]({% link soda-cl/metrics-and-checks.md %}#check-types), automated monitoring checks are unique. This check employs the `anomaly score` and `schema` checks, but is limited in its syntax variation, with only a couple of mutable parts to specify which datasets to automatically apply the anomaly and schema checks.
 
 The example check below uses a wildcard character (`%`) to specify that Soda Core executes automated monitoring checks against all datasets with names that begin with `prod`, and *not* to execute the checks against any dataset with a name that begins with `test`.
-
+{% include code-header.html %}
 ```yaml
 automated monitoring:
   datasets:
@@ -111,7 +111,7 @@ automated monitoring:
 <br />
 
 You can also specify individual datasets to include or exclude, as in the following example.
-
+{% include code-header.html %}
 ```yaml
 automated monitoring:
   datasets:
@@ -137,7 +137,7 @@ To review the checks results for automated monitoring checks in Soda Cloud, navi
 
 
 #### Example with wildcards 
-
+{% include code-header.html %}
 ```yaml
 automated monitoring:
   datasets:

soda-cl/check-attributes.md

@@ -9,7 +9,7 @@ parent: SodaCL
 *Last modified on {% last_modified_at %}*
 
 As a Soda Cloud Admin user, you can define **check attributes** that your team can apply to checks when they write them in an agreement or in a checks YAML file for Soda Core.
-
+{% include code-header.html %}
 ```yaml
 checks for dim_product:
   - missing_count(discount) < 10:
@@ -73,7 +73,7 @@ OR <br />
 * writing or editing checks in a checks YAML file for Soda Core.
 
 Apply attributes to checks using key:value pairs, as in the following example which applies five Soda Cloud-created attributes to a new `row_count` check. 
-
+{% include code-header.html %}
 ```yaml
 checks for dim_product:
   - row_count = 10:
@@ -106,7 +106,7 @@ Note that users must use the attribute's **NAME** as the attribute's key in a ch
 ## Optional check attribute SodaCL configurations
 
 Using SodaCL, you can use variables to populate either the key or value of an existing attribute, as in the following example. Refer to [Configure variables in SodaCL]({% link soda-cl/filters.md %}#configure-variables-in-sodacl) for further details. 
-
+{% include code-header.html %}
 ```yaml
 checks for dim_product:
   - row_count = 10:
@@ -116,7 +116,7 @@ checks for dim_product:
 ```
 
 You can use attributes in checks that Soda executes as part of a for each configuration, as in the following example. Refer to [Optional check configuration]({% link soda-cl/optional-config.md %}#apply-checks-to-multiple-datasets) for further details on for each.
-
+{% include code-header.html %}
 ```yaml
 for each dataset T:
  datasets:

soda-cl/compare.md

@@ -24,22 +24,22 @@ Have you got an idea or example of how to compare data that we haven't documente
 
 Use a [cross check]({% link soda-cl/cross-row-checks.md %}) to conduct a row count comparison between datasets in the same data source. <br /> 
 If you wish to compare datasets in different data sources, or datasets in the same data source but with different schemas, see [Compare data in different data sources or schemas](#compare-data-in-different-data-sources-or-schemas).
-
+{% include code-header.html %}
 ```yaml
 checks for dim_employee:
   - row_count same as dim_department_group
 ```
 
 Use a [reference check]({% link soda-cl/reference.md %}) to conduct a row-by-row comparison of values in two datasets _in the same data source_ and return a result that indicates the volume and samples of mismatched rows, as in the following example which ensures that the values in each of the two names columns are identical.<br />
 If you wish to compare datasets in the same data source but with different _schemas_, see [Compare data in different data sources or schemas](#compare-data-in-different-data-sources-or-schemas).
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customers_dev:
   - values in (last_name, first_name) must exist in dim_customers_prod (last_name, first_name)
 ```
 
 Alternatively, you can use a [failed rows check]({% link soda-cl/failed-rows-checks.md %}) to customize a SQL query that compares the values of datasets.
-
+{% include code-header.html %}
 ```yaml
 - failed rows:
       name: Validate that the data is the same as retail customers
@@ -79,7 +79,7 @@ Alternatively, you can use a [failed rows check]({% link soda-cl/failed-rows-che
 
 Use a [cross check]({% link soda-cl/cross-row-checks.md %}) to conduct a simple row count comparison of datasets in two different data sources, as in the following example that compares the row counts of two datasets in different data sources. <br />
 Note that each data source involved in this check has been connected to data source either in the `configuration.yml` file with Soda Core, or in the **Add Data Source** workflow in Soda Cloud.
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
   - row_count same as dim_customer in aws_postgres_retail
@@ -88,6 +88,7 @@ checks for dim_customer:
 You can use a [reference check]({% link soda-cl/reference.md %}) to compare the values of different datasets in the _same_ data source (same data source, same schema), but if the datasets are in different schemas, as might happen when you have different environments like production, staging, development, etc., then Soda considers those datasets as _different data sources_. Where that is the case, you have a couple of options.
 
 You can use a cross check to compare the row count of datasets in the same data source, but with different schemas. First, you must add dataset + schema as a separate data source connection in your `configuration.yml`, as in the following example that uses the same connection details but provides different schemas:
+{% include code-header.html %}
 ```yaml
 data_source retail_customers_stage:
   type: postgres
@@ -108,6 +109,7 @@ data_source retail_customers_prod:
   schema: production
 ```
 Then, you can define a cross check that compares values across these data sources.
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
 # Check row count between datasets in different data sources
@@ -117,7 +119,7 @@ checks for dim_customer:
 Alternatively, depending on the type of data source you are using, you can use a [failed rows check]({% link soda-cl/failed-rows-checks.md %}) to write a custom SQL query that compares contents of datasets that you define by adding the schema before the dataset name, such as `prod.retail_customers` and `staging.retail_customers`. 
 
 The following example accesses a single Snowflake data source and compares values between the same datasets but in different databases and schemas: `prod.staging.dmds_scores` and `prod.measurement.post_scores`.
-
+{% include code-header.html %}
 ```yaml
 - failed rows:
     fail query: |

soda-cl/cross-row-checks.md

@@ -13,7 +13,7 @@ redirect_from: /soda-cl/row-count.html
 Use a cross check to compare row counts between datasets within the same, or different, data sources.
 
 See also: [Compare data using SodaCL]({% link soda-cl/compare.md %})
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
 # Check row count between datasets in one data source
@@ -33,7 +33,7 @@ checks for dim_customer:
 In the context of [SodaCL check types]({% link soda-cl/metrics-and-checks.md %}#check-types), cross checks are unique. This check employs the `row_count` metric and is limited in its syntax variation, with only a few mutable parts to specify dataset and data source names.
 
 The example check below compares the volume of rows in two datasets in the same data source. If the row count in the `dim_department_group` is not the same as in `dim_customer`, the check fails.
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
   - row_count same as dim_department_group
@@ -44,7 +44,7 @@ checks for dim_customer:
 You can use cross checks to compare row counts between datasets in different data sources, as in the example below. 
 
 In the example, `retail_customers` is the name of the other dataset, and `aws_postgres_retail` is the name of the data source in which `retail_customers` exists.
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
   - row_count same as retail_customers in aws_postgres_retail
@@ -67,15 +67,15 @@ checks for dim_customer:
 |   | Apply a dataset filter to partition data during a scan; see [example](#example-with-dataset-filter). | - |
 
 #### Example with check name 
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
   - row_count same as retail_customers in aws_postgres_retail:
       name: Cross check customer datasets
 ```
 
 #### Example with quotes
-
+{% include code-header.html %}
 ```yaml
 checks for dim_customer:
   - row_count same as "dim_department_group"