Fix a bunch of code tags

lib/input/broker.go

@@ -39,7 +39,7 @@ field to specify how many copies of the list of inputs should be created.
 Adding more input types allows you to merge streams from multiple sources into
 one. For example, reading from both RabbitMQ and Kafka:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 input:
   broker:
     copies: 1

lib/output/aws_dynamodb.go

@@ -26,7 +26,7 @@ where the values are
 batch. This allows you to populate string columns of an item by extracting
 fields within the document payload or metadata like follows:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 string_columns:
   id: ${!json("id")}
   title: ${!json("body.title")}
@@ -40,15 +40,15 @@ converted into a map value. Both an empty path and the path ` + "`.`" + ` are
 interpreted as the root of the document. This allows you to populate map columns
 of an item like follows:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 json_map_columns:
   user: path.to.user
   whole_document: .
 ` + "```" + `
 
 A column name can be empty:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 json_map_columns:
   "": .
 ` + "```" + `

lib/output/azure_table_storage.go

@@ -31,7 +31,7 @@ are marshaled and stored in the table, which will be created if it does not exis
 The ` + "`object`" + ` and ` + "`array`" + ` fields are marshaled as strings. e.g.:
 
 The JSON message:
-` + "``` yaml" + `
+` + "```json" + `
 {
   "foo": 55,
   "bar": {
@@ -43,7 +43,7 @@ The JSON message:
 ` + "```" + `
 
 Will store in the table the following properties:
-` + "``` yaml" + `
+` + "```yaml" + `
 foo: '55'
 bar: '{ "baz": "a", "bez": "b" }'
 diz: '["a", "b"]'

lib/output/cache.go

@@ -35,7 +35,7 @@ and can target any of the following types:
 ` + cachesList + `
 The ` + "`target`" + ` field must point to a configured cache like follows:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 output:
   cache:
     target: foo

lib/output/drop_on_error.go

@@ -36,7 +36,7 @@ For example, the following configuration attempts to send to a hypothetical
 output type ` + "`foo`" + ` three times, but if all three attempts fail the
 message is dropped entirely:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 output:
   drop_on_error:
     retry:

lib/output/resource.go

@@ -23,7 +23,7 @@ allows you to run the same configured output resource in multiple places.`,
 Resource outputs also have the advantage of name based metrics and logging. For
 example, the config:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 output:
   broker:
     pattern: fan_out

lib/output/sync_response.go

@@ -27,7 +27,7 @@ It is safe to combine this output with others using broker types. For example,
 with the ` + "`http_server`" + ` input we could send the payload to a Kafka
 topic and also send a modified payload back with:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 input:
   http_server:
     path: /post

lib/output/try.go

@@ -24,7 +24,7 @@ targets have broken. For example, if you had an output type ` + "`http_client`"
 but wished to reroute messages whenever the endpoint becomes unreachable you
 could use this pattern:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 output:
   try:
   - http_client:

lib/processor/dedupe.go

@@ -44,10 +44,12 @@ For example, the following config would deduplicate based on the concatenated
 values of the metadata field ` + "`kafka_key`" + ` and the value of the JSON
 path ` + "`id`" + ` within the message contents:
 
-` + "``` yaml" + `
-dedupe:
-  cache: foocache
-  key: ${! meta("kafka_key") }-${! json("id") }
+` + "```yaml" + `
+pipeline:
+  processors:
+    - dedupe:
+        cache: foocache
+        key: ${! meta("kafka_key") }-${! json("id") }
 ` + "```" + `
 
 Caches should be configured as a resource, for more information check out the

lib/processor/group_by_value.go

@@ -40,7 +40,7 @@ If we were consuming Kafka messages and needed to group them by their key,
 archive the groups, and send them to S3 with the key as part of the path we
 could achieve that with the following:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 pipeline:
   processors:
   - group_by_value:

lib/processor/log.go

@@ -34,11 +34,13 @@ pipeline in order to expose the JSON field ` + "`foo.bar`" + ` as well as the
 metadata field ` + "`kafka_partition`" + ` we can achieve that with the
 following config:
 
-` + "``` yaml" + `
-for_each:
-- log:
-    level: DEBUG
-    message: 'field: ${! json("foo.bar") }, part: ${! meta("kafka_partition") }'
+` + "```yaml" + `
+pipeline:
+  processors:
+    - for_each:
+      - log:
+          level: DEBUG
+          message: 'field: ${! json("foo.bar") }, part: ${! meta("kafka_partition") }'
 ` + "```" + `
 
 The ` + "`level`" + ` field determines the log level of the printed events and
@@ -51,13 +53,15 @@ the service log is set to output as JSON. The field values are function
 interpolated, meaning it's possible to output structured fields containing
 message contents and metadata, e.g.:
 
-` + "``` yaml" + `
-log:
-  level: DEBUG
-  message: "foo"
-  fields:
-    id: '${! json("id") }'
-    kafka_topic: '${! meta("kafka_topic") }'
+` + "```yaml" + `
+pipeline:
+  processors:
+    - log:
+        level: DEBUG
+        message: "foo"
+        fields:
+          id: '${! json("id") }'
+          kafka_topic: '${! meta("kafka_topic") }'
 ` + "```" + ``,
 		FieldSpecs: docs.FieldSpecs{
 			docs.FieldCommon("level", "The log level to use.").HasOptions("FATAL", "ERROR", "WARN", "INFO", "DEBUG", "TRACE", "ALL"),

lib/processor/resource.go

@@ -27,7 +27,7 @@ places.`,
 Resource processors also have the advantage of name based metrics and logging.
 For example, the config:
 
-` + "``` yaml" + `
+` + "```yaml" + `
 pipeline:
   processors:
     - bloblang: |

lib/processor/sleep.go

@@ -31,10 +31,12 @@ This processor executes once per message batch. In order to execute once for
 each message of a batch place it within a
 ` + "[`for_each`](/docs/components/processors/for_each)" + ` processor:
 
-` + "``` yaml" + `
-for_each:
-- sleep:
-    duration: ${! meta("sleep_for") }
+` + "```yaml" + `
+pipeline:
+  processors:
+    - for_each:
+      - sleep:
+          duration: ${! meta("sleep_for") }
 ` + "```" + ``,
 		FieldSpecs: docs.FieldSpecs{
 			docs.FieldCommon("duration", "The duration of time to sleep for each execution."),

website/docs/components/inputs/broker.md

@@ -66,7 +66,7 @@ field to specify how many copies of the list of inputs should be created.
 Adding more input types allows you to merge streams from multiple sources into
 one. For example, reading from both RabbitMQ and Kafka:
 
-``` yaml
+```yaml
 input:
   broker:
     copies: 1

website/docs/components/outputs/aws_dynamodb.md

@@ -88,7 +88,7 @@ where the values are
 batch. This allows you to populate string columns of an item by extracting
 fields within the document payload or metadata like follows:
 
-``` yaml
+```yaml
 string_columns:
   id: ${!json("id")}
   title: ${!json("body.title")}
@@ -102,15 +102,15 @@ converted into a map value. Both an empty path and the path `.` are
 interpreted as the root of the document. This allows you to populate map columns
 of an item like follows:
 
-``` yaml
+```yaml
 json_map_columns:
   user: path.to.user
   whole_document: .
 ```
 
 A column name can be empty:
 
-``` yaml
+```yaml
 json_map_columns:
   "": .
 ```

website/docs/components/outputs/azure_table_storage.md

@@ -88,7 +88,7 @@ are marshaled and stored in the table, which will be created if it does not exis
 The `object` and `array` fields are marshaled as strings. e.g.:
 
 The JSON message:
-``` yaml
+```json
 {
   "foo": 55,
   "bar": {
@@ -100,7 +100,7 @@ The JSON message:
 ```
 
 Will store in the table the following properties:
-``` yaml
+```yaml
 foo: '55'
 bar: '{ "baz": "a", "bez": "b" }'
 diz: '["a", "b"]'

website/docs/components/outputs/cache.md

@@ -67,7 +67,7 @@ and can target any of the following types:
 
 The `target` field must point to a configured cache like follows:
 
-``` yaml
+```yaml
 output:
   cache:
     target: foo

website/docs/components/outputs/drop_on_error.md

@@ -39,7 +39,7 @@ For example, the following configuration attempts to send to a hypothetical
 output type `foo` three times, but if all three attempts fail the
 message is dropped entirely:
 
-``` yaml
+```yaml
 output:
   drop_on_error:
     retry:

website/docs/components/outputs/resource.md

@@ -28,7 +28,7 @@ output:
 Resource outputs also have the advantage of name based metrics and logging. For
 example, the config:
 
-``` yaml
+```yaml
 output:
   broker:
     pattern: fan_out

website/docs/components/outputs/sync_response.md

@@ -34,7 +34,7 @@ It is safe to combine this output with others using broker types. For example,
 with the `http_server` input we could send the payload to a Kafka
 topic and also send a modified payload back with:
 
-``` yaml
+```yaml
 input:
   http_server:
     path: /post

website/docs/components/outputs/try.md

@@ -31,7 +31,7 @@ targets have broken. For example, if you had an output type `http_client`
 but wished to reroute messages whenever the endpoint becomes unreachable you
 could use this pattern:
 
-``` yaml
+```yaml
 output:
   try:
   - http_client:

website/docs/components/processors/dedupe.md

@@ -67,10 +67,12 @@ For example, the following config would deduplicate based on the concatenated
 values of the metadata field `kafka_key` and the value of the JSON
 path `id` within the message contents:
 
-``` yaml
-dedupe:
-  cache: foocache
-  key: ${! meta("kafka_key") }-${! json("id") }
+```yaml
+pipeline:
+  processors:
+    - dedupe:
+        cache: foocache
+        key: ${! meta("kafka_key") }-${! json("id") }
 ```
 
 Caches should be configured as a resource, for more information check out the

website/docs/components/processors/group_by_value.md

@@ -59,7 +59,7 @@ If we were consuming Kafka messages and needed to group them by their key,
 archive the groups, and send them to S3 with the key as part of the path we
 could achieve that with the following:
 
-``` yaml
+```yaml
 pipeline:
   processors:
   - group_by_value:

website/docs/components/processors/log.md

@@ -37,11 +37,13 @@ pipeline in order to expose the JSON field `foo.bar` as well as the
 metadata field `kafka_partition` we can achieve that with the
 following config:
 
-``` yaml
-for_each:
-- log:
-    level: DEBUG
-    message: 'field: ${! json("foo.bar") }, part: ${! meta("kafka_partition") }'
+```yaml
+pipeline:
+  processors:
+    - for_each:
+      - log:
+          level: DEBUG
+          message: 'field: ${! json("foo.bar") }, part: ${! meta("kafka_partition") }'
 ```
 
 The `level` field determines the log level of the printed events and
@@ -54,13 +56,15 @@ the service log is set to output as JSON. The field values are function
 interpolated, meaning it's possible to output structured fields containing
 message contents and metadata, e.g.:
 
-``` yaml
-log:
-  level: DEBUG
-  message: "foo"
-  fields:
-    id: '${! json("id") }'
-    kafka_topic: '${! meta("kafka_topic") }'
+```yaml
+pipeline:
+  processors:
+    - log:
+        level: DEBUG
+        message: "foo"
+        fields:
+          id: '${! json("id") }'
+          kafka_topic: '${! meta("kafka_topic") }'
 ```
 
 ## Fields

website/docs/components/processors/resource.md

@@ -28,7 +28,7 @@ resource: ""
 Resource processors also have the advantage of name based metrics and logging.
 For example, the config:
 
-``` yaml
+```yaml
 pipeline:
   processors:
     - bloblang: |

website/docs/components/processors/sleep.md

@@ -30,10 +30,12 @@ This processor executes once per message batch. In order to execute once for
 each message of a batch place it within a
 [`for_each`](/docs/components/processors/for_each) processor:
 
-``` yaml
-for_each:
-- sleep:
-    duration: ${! meta("sleep_for") }
+```yaml
+pipeline:
+  processors:
+    - for_each:
+      - sleep:
+          duration: ${! meta("sleep_for") }
 ```
 
 ## Fields

website/docs/components/tracers/about.md

@@ -12,7 +12,7 @@ a work in progress and should eventually expand so that all inputs have a way of
 
 A tracer config section looks like this:
 
-``` yaml
+```yaml
 tracer:
   jaeger:
     agent_address: localhost:6831