Differences

This shows you the differences between two versions of the page.

--- bloglike:2021-07 [2021/07/20 12:59] – add link to SO and funny fact stybla
+++ bloglike:2021-07 [2021/07/21 09:29] (current) – link terraform issue stybla
@@ Line 26: / Line 26: @@
 </code>
-I haven't found another way to do it nor how to deal with nested data(lists and dicts), eg. ''{"resources": ["arn:aws:..."]}'', therefore it seems that you must do without. All other fields I've tried to smuggle in have been stripped away, at least in my case. If you turn ''message'' into dict, then there will be ''{'' in CloudWatch Logs. Also noteworthy, if escaped JSON is invalid, the result will be a failed invocation and data won't make it into CloudWatch Logs. In theory, you can send output into SQS dead-letter queue when it cannot be delivered, but I haven't tested it. I should've tested it, though, because I bet it'd make debugging a lot easier since I couldn't find related logs anywhere!
+Meh! I haven't found another way to do it nor how to deal with nested data(lists and dicts), eg. ''{"resources": ["arn:aws:..."]}'', therefore it seems that you must do without. All other fields I've tried to smuggle in have been stripped away, at least in my case. If you turn ''message'' into dict, then there will be ''{'' in CloudWatch Logs. Note that if escaped JSON is invalid, the result will be a failed invocation and data won't make it into CloudWatch Logs. In theory, you can send output into SQS dead-letter queue when it cannot be delivered, but I haven't tested it. I should've tested it, though, because I bet it'd make debugging a lot easier since I couldn't find related logs anywhere!
 I guess all of this could've been done much faster and less painful with a simple Lambda function, but then you have code to maintain and deploy.
-Hopefully the last thing. Beware of this [[https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/351#issue-552650814|bug]]. Over and out.
+Couple more things. Beware of this [[https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/351#issue-552650814|bug]].
-**EDIT** since I'm cleaning up here:
 > Note: CloudWatch Events currently supports a maximum of 10 variables in input path maps. To extract more than 10 variables, pass the entire event to an AWS Lambda function for parsing.
-Well, I able to parse 13 variables. Lucky me, I guess. 8-) But as I've said, yeah, use Lambda function, if you can.
+Well, I able to parse 13 variables. Lucky me, I guess. 8-) Or maybe not, because when I've tried to put this into terraform, then:
+<code>
+Error: expected number of items in input_transformer.0.input_paths to be less than or equal to 10, got 16
+</code>
+To that I say, bollocks! It works no-problem from the console, so why would you ...?! [[https://github.com/hashicorp/terraform-provider-aws/issues/10912|Geee, thanks!]] :-\ As I've said, use Lambda function, if you can. Yeah, anything but CloudWatch Logs.
+You can filter which events get processed like so:
+<code>
+{
+  "source": [
+    "aws.batch"
+  ],
+  "detail-type": [
+    "Batch Job State Change"
+  ],
+  "detail": {
+    "status": [
+      "FAILED",
+      "SUCCEEDED"
+    ]
+  }
+}
+</code>
+This means only ''FAILED'' and ''SUCCEEDED'' Batch Job State changes will be processed and forwarded to rule's target(output).
  --- //[[stybla@turnovfree.net|Zdenek Styblik]] 2021/07/20 17:18//