ufo 3.5.4 → 3.5.5

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 5a7fa29c3df7ba9a608f0e2c82fd27231fa6f083136ba3a08b987067518de477
-  data.tar.gz: 94c3f8f4e5fc4b2cc9cf8fcac9ef49e42d876a137cfd414a10d62c915da7c96d
+  metadata.gz: 2f3cffb0c5f3bb15b7f6a236fab1821ec671a0a58f316d05546b0cc2343df31f
+  data.tar.gz: 0cbe0fe89dad15e6501ec136ecf5eb762861b6827939d520616d16d871a7bbaa
 SHA512:
-  metadata.gz: eac7a33bea59ff2420a63ece5779c874a7b9bb03d6a5856417cb87d330a657a3fdb35888ee971545703b00bfa5e9887490efc0657cf0c4ccaeb6f717e9f29387
-  data.tar.gz: b0b8e6d712982eea6a6f58c4eefbb172da9bfef85ae4e5a2d23e69c30fa47059238175bbb1c0902cade9f9af3a16d2bdfd8c66b072906076c6fd3017d1303209
+  metadata.gz: 19ccd9c0ed6f4cb8b2277e5895e3a92effdf47b40ea6424b1f64cc158f73182c402feebdc3fae45234b10b1b92f3b039b85b76ce5047fb61a554b42016a16f73
+  data.tar.gz: 633bc8eba241b343ee35e7927fd2d47bd609b5ca370096de8ab39581cd1608bac757e111a7b1cd02fc44b3b03b818a5848003523e84de57a6b32aab3980424cd

data/CHANGELOG.md

@@ -3,6 +3,12 @@
 All notable changes to this project will be documented in this file.
 This project *tries* to adhere to [Semantic Versioning](http://semver.org/), even before v1.0.
 
+## [3.5.5]
+- Merge pull request #39 from hnatt/fix-docs
+- Merge pull request #41 from tongueroo/params-template-scope
+- add cloudwatch log info for the task command
+- pass template scope to params erb evaluation
+
 ## [3.5.4]
 - Merge pull request #38 from tongueroo/docker-build-options
 - add ability to specify custom docker build options with env UFO_DOCKER_BUILD_OPTIONS variable

data/CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing to Lono
+# Contributing to ufo
 
 Contributing is welcomed and encouraged.  We love pull requests!
 

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    ufo (3.5.4)
+    ufo (3.5.5)
       aws-sdk-cloudwatchlogs
       aws-sdk-ec2
       aws-sdk-ecr
@@ -27,7 +27,7 @@ GEM
     aws-sdk-cloudwatchlogs (1.3.0)
       aws-sdk-core (~> 3)
       aws-sigv4 (~> 1.0)
-    aws-sdk-core (3.21.1)
+    aws-sdk-core (3.21.2)
       aws-eventstream (~> 1.0)
       aws-partitions (~> 1.0)
       aws-sigv4 (~> 1.0)
@@ -38,10 +38,10 @@ GEM
     aws-sdk-ecr (1.3.0)
       aws-sdk-core (~> 3)
       aws-sigv4 (~> 1.0)
-    aws-sdk-ecs (1.12.0)
+    aws-sdk-ecs (1.13.0)
       aws-sdk-core (~> 3)
       aws-sigv4 (~> 1.0)
-    aws-sdk-elasticloadbalancingv2 (1.8.0)
+    aws-sdk-elasticloadbalancingv2 (1.9.0)
       aws-sdk-core (~> 3)
       aws-sigv4 (~> 1.0)
     aws-sigv4 (1.0.2)

data/docs/_docs/conventions.md

@@ -31,13 +31,13 @@ end
 
 ## Web Role Convention
 
-By convention, if the service has a container name web, you'll get prompted to create an ELB and specify a target group arn.  If you would like to name a service with the word "web" in it without having to use an ELB target group then you can use the `--no-target-group-prompt`.  Example:
+By convention, if the service has a container named "web", you'll get prompted to create an ELB and specify a target group ARN.  If you would like to name a service with the word "web" in it without having to use an ELB target group then you can use the `--no-target-group-prompt`.  Example:
 
 ```sh
 ufo ship hi-web --no-target-group-prompt
 ```
 
-You can also bypass the prompt by specifying the target group arn as part of the command upfront. The ELB and target group must already exist.  The elb target group only gets associated when the service gets created for the first time.  If the service already exists then the `--target-group` parameter just gets ignored and the ECS task simply gets updated.  Example:
+You can also bypass the prompt by specifying the target group ARN as part of the command upfront. The ELB and target group must already exist.  The ELB target group only gets associated when the service gets created for the first time.  If the service already exists then the `--target-group` parameter just gets ignored and the ECS task simply gets updated.  Example:
 
 ```bash
 ufo ship hi-web --target-group=arn:aws:elasticloadbalancing:us-east-1:12345689:targetgroup/hi-web/12345

data/docs/_docs/faq.md

@@ -4,11 +4,12 @@ title: FAQ
 
 **Q: Is AWS ECS Fargate supported?**
 
-Yes, Fargate is supported.  To use ufo with Fargate, you will need to adjust the template in `.ufo/templates` to use a structure support by Fargate.  If it's a brand new project. You can use `ufo init` with the `--launch-type fargate` option and it will generate a starter JSON file that has the right Fargate structure. Notably, it has the requiresCompatibilities, networkMode, and executionRoleArn attributes.
+Yes, Fargate is supported.  To use ufo with Fargate, you will need to adjust the template in `.ufo/templates` to use a structure support by Fargate.  There are 2 key items to adjust:
 
-The neat thing about Fargate is that can be an extremely cost-effective way to run one-off tasks. This blog post [Heroku vs ECS Fargate vs EC2 On-Demand vs EC2 Spot Pricing Comparison](https://blog.boltops.com/2018/04/22/heroku-vs-ecs-fargate-vs-ec2-on-demand-vs-ec2-spot-pricing-comparison) provides a relative comparison of costs.
+1. The task definition json. Notably, it has the `requiresCompatibilities`, `networkMode`, and `executionRoleArn` attributes. It also moves the `cpu` and `memory` outside of the `containerDefinitions` attributes to the root as top-level attributes. For details on how to adjust the task definition refer to [Task Definitions]({% link _docs/tutorial-ufo-tasks-build.md %}).
+2. The params that get sent to the `create_service` or  `run_task` api methods. For details on how to adjust the params refer to [Params]({% link _docs/params.md %})
 
----
+If it's a brand new project, you can use `ufo init` with the `--launch-type fargate` option and it will generate a starter JSON file that has the right Fargate structure. More info is available at [ufo init reference](/reference/ufo-init/#fargate-support).
 
 **Q: Can I tell ufo to use specific docker build options?**
 
@@ -74,7 +75,7 @@ Yes, this is achieved with the `--template` and `--template-mode` options when c
 
 ---
 
-**Q: How can I used syslog instead of awslogs for logging?**
+**Q: How can I use syslog instead of awslogs for logging?**
 
 Open up `.ufo/templates/main.json.erb` - this gets created as part of the [ufo init](http://ufoships.com/reference/ufo-init/) command.  Then you can adjust the ecs template definition to something like this:
 
@@ -86,7 +87,7 @@ Open up `.ufo/templates/main.json.erb` - this gets created as part of the [ufo i
 
 Here's the specific aws docs section [Specifying a Log Configuration in your Task Definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html#specify-log-config)
 
-Also, you might have to enable the log driver by added it the ECS_AVAILABLE_LOGGING_DRIVERS variable to your `/etc/ecs/ecs.config`. Relevant docs:
+Also, you might have to enable the log driver by adding the ECS_AVAILABLE_LOGGING_DRIVERS variable to your `/etc/ecs/ecs.config`. Relevant docs:
 
 * [Using AWS Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html#enable_awslogs)
 * [ECS Agent Install](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html)

data/docs/_docs/migrations.md

@@ -8,7 +8,7 @@ A common task is to run database migrations with newer code before deploying the
 ufo task hi-web --command bundle exec rake db:migrate
 ```
 
-It nice to wrap the commands in a wrapper script in case you have to do things like the load the environment.
+It is nice to wrap the commands in a wrapper script in case you have to do things like to load the environment.
 
 ```sh
 ufo task hi-web --command bin/migrate

data/docs/_docs/params.md

@@ -55,9 +55,11 @@ Ufo provides 1st class citizen access to adjust the params sent to the aws-sdk c
 * update_service - `ufo ship` calls this when the ECS service already exists.
 * run_task - `ufo task` calls this.
 
-The parameters from this `params.yml` file gets merged with params ufo generates internally.  Here's an example of where the merging happens in the source code for the run task command [task.rb](https://github.com/tongueroo/ufo/blob/90f12df035843528770122deb328d150249a25e2/lib/ufo/task.rb#L20)  Also, here's the starter [params.yml source code](https://github.com/tongueroo/ufo/blob/master/lib/template/.ufo/params.yml) for reference.
+The parameters from this `params.yml` file get merged with params ufo generates internally.  Here's an example of where the merging happens in the source code for the run task command [task.rb](https://github.com/tongueroo/ufo/blob/90f12df035843528770122deb328d150249a25e2/lib/ufo/task.rb#L20).  Also, here's the starter [params.yml source code](https://github.com/tongueroo/ufo/blob/master/lib/template/.ufo/params.yml) for reference.
 
-ERB and variables are available in the params file.  Noticed how ERB is used at the top of the example file to set some subnets to prevent duplication.
+ERB and [shared variables]({% link _docs/variables.md %}) are available in the params file.  Notice how ERB is used at the top of the example file to set some subnets to prevent duplication. You can also define the subnets in your config/variables and use them in them in the params.yml file.
+
+NOTE: The params.yml file does not have access to the `task_definition_name` helper method. That is only available in the `task_definitions.rb` template_definition code blocks.
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/settings.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/ufo-env.md %}">Next Step</a>

data/docs/_docs/run-in-pieces.md

@@ -30,7 +30,7 @@ Update the service with the task definitions in `.ufo/output` untouched.
 ufo deploy hi-web
 ```
 
-Note if you use the `ufo deploy` you should ensure that you have already push the docker image to your docker registry.  Or else the task will not be able to spin up because the docker image does not exist.  This is one of the reasons it is recommended that you use `ufo ship`.
+Note if you use the `ufo deploy` you should ensure that you have already pushed the docker image to your docker registry.  Or else the task will not be able to spin up because the docker image does not exist.  This is one of the reasons it is recommended that you use `ufo ship`.
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/auto-completion.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/single-task.md %}">Next Step</a>

data/docs/_docs/settings.md

@@ -103,7 +103,7 @@ AWS_PROFILE=dev-profile2 => UFO_ENV=development
 AWS_PROFILE=prod-profile => UFO_ENV=production
 ```
 
-This behavior prevents you from switching `AWS_PROFILE`s and then accidentally deploying a production based docker image to development and vice versas because you forgot to also switch `UFO_ENV` to its respective environment.
+This behavior prevents you from switching `AWS_PROFILE`s and then accidentally deploying a production based docker image to development and vice versa because you forgot to also switch `UFO_ENV` to its respective environment.
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/structure.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/params.md %}">Next Step</a>

data/docs/_docs/structure.md

@@ -21,14 +21,14 @@ The table below covers the purpose of each folder and file.
 
 File / Directory  | Description
 ------------- | -------------
-<code>output/</code>  | The folder where the generated task definitions are written to.  The way the task definitions are generated are covered in [ufo tasks build]({% link _docs/tutorial-ufo-tasks-build.md %}).
-<code>settings.yml</code>  | Ufo's settings file, where you and adjust the default [settings]({% link _docs/settings.md %}).
-<code>task_definitions.rb</code>  | This where you define the task definitions and specify the variables to be used by the ERB templates.
-<code>templates/</code>  | The ERB templates with the task definition json code.  The template are covered in more detail in [ufo tasks build]({% link _docs/tutorial-ufo-tasks-build.md %}).
+<code>output/</code>  | The folder where the generated task definitions are written to.  The way the task definitions are generated is covered in [ufo tasks build]({% link _docs/tutorial-ufo-tasks-build.md %}).
+<code>settings.yml</code>  | Ufo's settings file, where you adjust the default [settings]({% link _docs/settings.md %}).
+<code>task_definitions.rb</code>  | This is where you define the task definitions and specify the variables to be used by the ERB templates.
+<code>templates/</code>  | The ERB templates with the task definition json code.  The templates are covered in more detail in [ufo tasks build]({% link _docs/tutorial-ufo-tasks-build.md %}).
 <code>templates/main.json.erb</code>  | This is the main and starter template task definition json file that ufo initially generates.
-<code>variables</code>  | This is where you can define shared variables that are made available to the template_definitions.rb and your templates. More info at [Variables]({% link _docs/variables.md %}).
+<code>variables</code>  | This is where you can define shared variables that are made available to the `template_definitions.rb` and your templates. More info at [Variables]({% link _docs/variables.md %}).
 
-Now that you know where the ufo configurations are located and what they look like.  Let use ufo!
+Now that you know where the ufo configurations are located and what they look like, let’s use ufo!
 
 <a id="prev" class="btn btn-basic" href="{% link docs.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/settings.md %}">Next Step</a>

data/docs/_docs/tutorial-ufo-init.md

@@ -3,7 +3,7 @@ title: Setup Ufo
 ---
 
 The easiest way to create this ufo folder is by using the `ufo init` command.  For this tutorial we'll [tongueroo/hi](https://github.com/tongueroo/hi) which is a small test sinatra app.
-Let's run the command in our newly clone project.
+Let's run the command in our newly cloned project.
 
 ```sh
 git clone https://github.com/tongueroo/hi.git

data/docs/_docs/tutorial-ufo-ship.md

@@ -27,7 +27,7 @@ If the ECS service hi-web does not yet exist, ufo will create the service for yo
 
 NOTE: If you are relying on this tool to create the cluster, you still need to associate ECS Container Instances to the cluster yourself.
 
-By convention, if the service has a container name web, you'll get prompted to create an ELB and specify a target group arn.  The ELB and target group must already exist. You can bypass the prompt and specify the target group ARN as part of the ship command or with the `--no-target-group-prompt` option.  The elb target group only gets associated with the ECS service if the service is being created for the first time.  If the service already exists then the `--target-group` parameter just gets ignored and the ECS task simply gets updated.  Example:
+By convention, if the service has a container name web, you'll get prompted to create an ELB and specify a target group ARN.  The ELB and target group must already exist. You can bypass the prompt and specify the target group ARN as part of the ship command or with the `--no-target-group-prompt` option.  The ELB target group only gets associated with the ECS service if the service is being created for the first time.  If the service already exists then the `--target-group` parameter just gets ignored and the ECS task simply gets updated.  Example:
 
 
 ```bash
@@ -95,3 +95,6 @@ Normally you run everything together in one `ufo ship` command though.  Ufo take
 
 Congratulations 🎊 You have successfully built a Docker image, register it and deployed it to AWS ECS.
 
+<a id="prev" class="btn btn-basic" href="{% link _docs/tutorial-ufo-tasks-build.md %}">Back</a>
+<a id="next" class="btn btn-primary" href="{% link _docs/tutorial-ufo-ships.md %}">Next Step</a>
+<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>

data/docs/_docs/tutorial-ufo-tasks-build.md

@@ -8,12 +8,12 @@ Now that we have a docker image pushed to a registry we can use that image for E
 
 Let's take a look at the 2 files that are used by ufo to build the ECS task definition.  These files were generated by the `ufo init` command at the beginning.
 
-1. ufo/templates/main.json.erb
-2. ufo/task_definitions.rb
+1. `.ufo/templates/main.json.erb`
+2. `.ufo/task_definitions.rb`
 
 Ufo task definitions are written as an ERB template that makes it every easily accessible and configurable to your requirements.  Here is is an example of an ERB template `.ufo/templates/main.json.erb` that shows how easy it is to modfied the task definition you want to be uploaded by ufo:
 
-**ufo/templates/main.json.erb**:
+**.ufo/templates/main.json.erb**:
 
 ```json
 {
@@ -36,7 +36,7 @@ Ufo task definitions are written as an ERB template that makes it every easily a
 
 The instance variable values are specified in `.ufo/task_definitions.rb` via a DSL.  Here's the file:
 
-**ufo/task_definitions.rb**:
+**.ufo/task_definitions.rb**:
 
 ```
 task_definition "hi-web" do
@@ -63,7 +63,7 @@ end
 
 Ufo has a concept of shared variables, covered in [Shared Variables]({% link _docs/variables.md %}). The shared variables are set in the `variables` folder and essentially allow you to use a set of shared variables through your templates:
 
-**ufo/variables/base.rb**:
+**.ufo/variables/base.rb**:
 
 ```ruby
 @image = helper.full_image_name # includes the git sha tongueroo/hi:ufo-[sha].
@@ -72,7 +72,7 @@ Ufo has a concept of shared variables, covered in [Shared Variables]({% link _do
 @environment = helper.env_file(".env")
 ```
 
-**ufo/variables/development.rb**:
+**.ufo/variables/development.rb**:
 
 ```ruby
 @environment = helper.env_vars(%Q{
@@ -85,7 +85,7 @@ Ufo combines the `main.json.erb` template, `task_definitions.rb` definitions, an
 
 If you need to modify the task definition template to suite your own needs it is super simple, just edit `main.json.erb`.  You do not have to dive deep into internal code somewhere.  It is all there for you to fully control.
 
-The task_definition.rb has access to some useful helper methods detailed in [Helpers]({% link _docs/helpers.md %}).
+The `task_definition.rb` has access to some useful helper methods detailed in [Helpers]({% link _docs/helpers.md %}).
 
 Let's build the task definitions:
 
@@ -150,7 +150,7 @@ Let's take a look at one of the generated files: `.ufo/output/hi-web.json`.
 
 ## Register the ECS Task Definitions
 
-You have built the ecs task definitions locally on your machine. To register the task definitions in the `output` folder run:
+You have built the ECS task definitions locally on your machine. To register the task definitions in the `output` folder run:
 
 ```sh
 ufo tasks register

data/docs/_docs/ufo-env.md

@@ -27,7 +27,7 @@ ufo ship hi-web
 
 Most people will set `UFO_ENV` in their `~/.profile`.
 
-## In ufo/settings.yml
+## In .ufo/settings.yml
 
 The most interesting way to set `UFO_ENV` is with the `aws_profiles` setting in `.ufo/settings.yml`.  Let's say you have a `~/.ufo/settings.yml` with the following:
 

data/docs/_docs/variables.md

@@ -13,7 +13,7 @@ For example, given `variables/base.rb`:
 @environment = helper.env_file(".env")
 ```
 
-You can now use `@image` in your `.ufo/templates/main.json.erb` without having to explicitly declaring them in the `.ufo/task_definitions.rb` file.  Variables are automatically made available to all templates and the `task_definition.rb` file also.
+You can now use `@image` in your `.ufo/templates/main.json.erb` without having to explicitly declare them in the `.ufo/task_definitions.rb` file.  Variables are automatically made available to all templates and the `task_definition.rb` file also.
 
 ## Layering
 
@@ -28,7 +28,7 @@ Shared variables also support a concept called layering.  The `variables/base.rb
 @environment = helper.env_file(".env")
 ```
 
-When `ufo ship` is ran with `UFO_ENV=production` he `variables/production.rb` will be evaluated and layered on top of the variables defined in `base.rb`:
+When `ufo ship` is ran with `UFO_ENV=production` the `variables/production.rb` will be evaluated and layered on top of the variables defined in `base.rb`:
 
 `.ufo/variables/production.rb`:
 

data/lib/ufo/dsl.rb

@@ -1,11 +1,11 @@
 require 'ostruct'
 
 module Ufo
-  autoload :TaskDefinition, 'ufo/dsl/task_definition'
-  autoload :Outputter, 'ufo/dsl/outputter'
-  autoload :Helper, 'ufo/dsl/helper'
-
   class DSL
+    autoload :TaskDefinition, 'ufo/dsl/task_definition'
+    autoload :Outputter, 'ufo/dsl/outputter'
+    autoload :Helper, 'ufo/dsl/helper'
+
     def initialize(template_definitions_path, options={})
       @template_definitions_path = template_definitions_path
       @options = options

data/lib/ufo/param.rb

@@ -12,11 +12,15 @@ module Ufo
     def data
       upgrade_message!
 
-      result = RenderMePretty.result(@params_path)
+      result = RenderMePretty.result(@params_path, context: template_scope)
       YAML.load(result)
     end
     memoize :data
 
+    def template_scope
+      @template_scope ||= Ufo::TemplateScope.new(Ufo::DSL::Helper.new, nil)
+    end
+
     # Ufo version 3.3 to 3.4 added a concept of a .ufo/params.yml file to support
     # fargate: https://github.com/tongueroo/ufo/pull/31
     #

data/lib/ufo/task.rb

@@ -1,5 +1,9 @@
+require 'memoist'
+
 module Ufo
   class Task
+    extend Memoist
+
     include Util
     include AwsService
 
@@ -29,20 +33,51 @@ module Ufo
         puts "Running task with params:"
         display_params(task_options)
       end
-      resp = ecs.run_task(task_options)
+
+      resp = run_task(task_options)
       unless @options[:mute]
         task_arn = resp.tasks[0].task_arn
         puts "Task ARN: #{task_arn}"
         puts "  aws ecs describe-tasks --tasks #{task_arn} --cluster #{@cluster}"
-        # todo: maybe add cw comand here also
+        cloudwatch_info(task_arn)
+      end
+    end
+
+    def run_task(options)
+      ecs.run_task(options)
+    rescue Aws::ECS::Errors::ClientException => e
+      if e.message =~ /ECS was unable to assume the role/
+        puts "ERROR: #{e.class} #{e.message}".colorize(:red)
+        puts "Please double check the executionRoleArn in your task definition."
+        exit 1
+      else
+        raise
       end
     end
 
   private
+    def cloudwatch_info(task_arn)
+      config = original_container_definition[:log_configuration]
+      container_name = original_container_definition[:name]
+
+      return unless config && config[:log_driver] == "awslogs"
+
+      log_group = config[:options]["awslogs-group"]
+      log_stream_prefix = config[:options]["awslogs-stream-prefix"]
+      task_id = task_arn.split('/').last
+      log_stream = "#{log_stream_prefix}/#{container_name}/#{task_id}"
+      # website/web/d473440a-9a0e-4262-a53d-f9e345cf2b7e
+      region = `aws configure get region`.strip rescue 'us-east-1'
+      url = "https://#{region}.console.aws.amazon.com/cloudwatch/home?region=#{region}#logEventViewer:group=#{log_group};stream=#{log_stream}"
+
+      puts "To see the task output visit CloudWatch:\n  #{url}"
+      puts "NOTE: It will take some time for the log to show up because it takes time for the task to start. Run the `aws ecs describe-tasks` above for the task status."
+    end
+
     # only using the overrides to override the container command
     def overrides
       command = @options[:command] # Thor parser ensure this is always an array
-      container_definition = get_original_container_definition
+      container_definition = original_container_definition
       {
         container_overrides: [
           {
@@ -54,7 +89,7 @@ module Ufo
       }
     end
 
-    def get_original_container_definition
+    def original_container_definition
       resp = ecs.list_task_definitions(
         family_prefix: @task_definition,
         sort: "DESC"
@@ -65,5 +100,6 @@ module Ufo
       resp = ecs.describe_task_definition(task_definition: task_name)
       container_definition = resp.task_definition.container_definitions[0].to_h
     end
+    memoize :original_container_definition
   end
 end

data/lib/ufo/version.rb

@@ -1,3 +1,3 @@
 module Ufo
-  VERSION = "3.5.4"
+  VERSION = "3.5.5"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: ufo
 version: !ruby/object:Gem::Version
-  version: 3.5.4
+  version: 3.5.5
 platform: ruby
 authors:
 - Tung Nguyen
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2018-05-19 00:00:00.000000000 Z
+date: 2018-05-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: aws-sdk-cloudwatchlogs