ufo 3.1.2 → 3.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 82ae766d7898605cd34a3c649d78b9b09167032da7671f2b96c2d48a9f399869
-  data.tar.gz: 071b075649fad43445e648212f5f0757b9f3fb8dbf26a8ffd66edb636f6cdcc6
+  metadata.gz: c1894588cde21064b0558cbe90861eddc03879b7ff874906f39a6375998d5667
+  data.tar.gz: b613a20c65a8d7c8e9bb7b436c923fcf19f3a0514d054dc5e5a4919d03c4890d
 SHA512:
-  metadata.gz: 342dc28256785eaf52a64e86dbf1a3f8287e5297697ab69dbf864ca61846089491a87d77cec1e4998708a2a26a6e05c2f17973cb2f93499355fc56e28e1582e8
-  data.tar.gz: 71f1508d882070f67a7b10b3088cd98a522f37897891beeec2202943eee55826856c3189541a6db1cb31c92d4a9eade3abbbe4b1e1c00397f55012fcbcf07d1a
+  metadata.gz: 36c17e42e5a9f317058565338bde9e0c5cfd249152df58271554e8303378fd559687f348c1a5134e027d29842d9473489e7b45db937950f23a5e455578637c3c
+  data.tar.gz: 9e57675fbf2129208255cefeecc94849968d56aa1c868a30837fc813a710d7a0d2c7c0d7f5d85bf8e067662fd6c03e90e2cc9729ee70717ba5d47a227e079fe6

data/.circleci/bin/commit_docs.sh

@@ -0,0 +1,26 @@
+#!/bin/bash -eux
+
+# Even though specs also generate docs, lets run again to ensure clean slate
+rake docs
+
+out=$(git status docs)
+if [[ "$out" = *"nothing to commit"* ]]; then
+  exit
+fi
+
+COMMIT_MESSAGE="docs updated by circleci"
+
+# If the last commit already updated the docs, then exit.
+# Preventable measure to avoid infinite loop.
+if git log -1 --pretty=oneline | grep "$COMMIT_MESSAGE" ; then
+  exit
+fi
+
+# If reach here, we have some changes on docs that we should commit.
+# Even though s
+git add docs
+git commit -m "$COMMIT_MESSAGE"
+
+# https://makandracards.com/makandra/12107-git-show-current-branch-name-only
+current_branch=$(git rev-parse --abbrev-ref HEAD)
+git push origin "$current_branch"

data/.circleci/config.yml

@@ -42,6 +42,13 @@ jobs:
             - ./vendor/bundle
           key: v1-dependencies-{{ checksum "Gemfile" }}
 
+      # specs need git configured ad commit_docs.sh required it also
+      - run:
+          name: configure git
+          command: |
+            git config --global user.email "tongueroo@gmail.com"
+            git config --global user.name "Tung Nguyen"
+
       # run tests!
       - run:
           name: run tests
@@ -49,6 +56,12 @@ jobs:
             mkdir /tmp/test-results
             bundle exec rspec
 
+      - run:
+          name: commit cli reference docs
+          command: |
+            chmod a+x -R .circleci/bin
+            .circleci/bin/commit_docs.sh
+
       # collect reports
       - store_test_results:
           path: /tmp/test-results

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.2.0]
+- pr #23 from tongueroo/cli_markdown: http://ufoships.com/reference/ section now available
+- pr #24 from tongueroo/circleci
+- pr #25 from tongueroo/ecr-auth-legacy-docker-fix: ecr auth: also write legacy_entry to .docker/config.json
+- fix ensure_cluster_exist for inactive cluster bug fix
+
 ## [3.1.2]
 - upgrade3 updates .gitignore also
 

data/Gemfile.lock

@@ -1,12 +1,13 @@
 PATH
   remote: .
   specs:
-    ufo (3.1.0)
+    ufo (3.1.2)
       aws-sdk-cloudwatchlogs
       aws-sdk-ec2
       aws-sdk-ecr
       aws-sdk-ecs
       aws-sdk-elasticloadbalancingv2
+      cli_markdown
       colorize
       deep_merge
       plissken
@@ -21,7 +22,7 @@ GEM
       i18n (~> 0.7)
       minitest (~> 5.1)
       tzinfo (~> 1.1)
-    aws-partitions (1.65.0)
+    aws-partitions (1.67.0)
     aws-sdk-cloudwatchlogs (1.2.0)
       aws-sdk-core (~> 3)
       aws-sigv4 (~> 1.0)
@@ -38,11 +39,12 @@ GEM
     aws-sdk-ecs (1.8.0)
       aws-sdk-core (~> 3)
       aws-sigv4 (~> 1.0)
-    aws-sdk-elasticloadbalancingv2 (1.7.0)
+    aws-sdk-elasticloadbalancingv2 (1.8.0)
       aws-sdk-core (~> 3)
       aws-sigv4 (~> 1.0)
     aws-sigv4 (1.0.2)
     byebug (10.0.0)
+    cli_markdown (0.1.0)
     codeclimate-test-reporter (1.0.8)
       simplecov (<= 0.13)
     colorize (0.8.1)
@@ -57,7 +59,7 @@ GEM
     minitest (5.11.3)
     plissken (1.2.0)
     rake (12.3.0)
-    render_me_pretty (0.7.0)
+    render_me_pretty (0.7.1)
       activesupport
       colorize
       tilt

data/Rakefile

@@ -4,3 +4,10 @@ require "rspec/core/rake_task"
 task :default => :spec
 
 RSpec::Core::RakeTask.new
+
+require_relative "lib/ufo"
+require "cli_markdown"
+desc "Generates cli reference docs as markdown"
+task :docs do
+  CliMarkdown::Creator.create_all(cli_class: Ufo::CLI, cli_name: "ufo")
+end

data/docs/_config.yml

@@ -61,6 +61,9 @@ collections:
   docs:
     name: "Documentation"
     output: true
+  reference:
+    name: "Reference"
+    output: true
 
 defaults:
   - values:

data/docs/_docs/conventions.md

@@ -4,11 +4,11 @@ title: Conventions
 
 Ufo uses a set of naming conventions.  This helps enforce some best practices and also allows the ufo commands to be concise.  Ufo allows you to easily override or bypass the conventions if you need it.
 
-### UFO_ENV to ECS Cluster Convention
+## UFO_ENV to ECS Cluster Convention
 
 By default, the ECS cluster value is the same as UFO_ENV's value.  So if `UFO_ENV=production` then the ECS Cluster is `production` and if `UFO_ENV=development` then the ECS Cluster is `development`.  You can easily override this convention by specifying the `--cluster` CLI option.  You can also override this behavior with [settings.yml]({% link _docs/settings.md %}) to spare you from having to type `--cluster` over and over.
 
-### Service and Task Names Convention
+## Service and Task Names Convention
 
 Ufo assumes a convention that service\_name and the task\_name are the same. If you would like to override this convention then you can specify the task name.
 
@@ -29,7 +29,7 @@ end
 
 ```
 
-### Web Role Convention
+## 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:
 

data/docs/_docs/install.md

@@ -2,7 +2,7 @@
 title: Installation
 ---
 
-### Install with RubyGems
+## Install with RubyGems
 
 You can install ufo with RubyGems:
 
@@ -16,7 +16,7 @@ Or you can add ufo to your Gemfile in your project if you are working with a rub
 gem "ufo"
 {% endhighlight %}
 
-### Install with Bolts Toolbelt
+## Install with Bolts Toolbelt
 
 If you want to quickly install ufo without having to worry about ufo's dependencies you can simply install the Bolts Toolbelt which has ufo included.
 
@@ -26,12 +26,12 @@ brew cask install boltopslabs/software/bolts
 
 For more information about the Bolts Toolbelt or to get an installer for another operating system visit: [https://boltops.com/toolbelt](https://boltops.com/toolbelt)
 
-### Dependencies
+## Dependencies
 
 * Docker: You will need a working version of [Docker](https://docs.docker.com/engine/installation/) installed as ufo shells out and calls the `docker` command.
 * AWS: Set up your AWS credentials at `~/.aws/credentials` and `~/.aws/config`.  This is the [AWS standard way of setting up credentials](https://aws.amazon.com/blogs/security/a-new-and-standardized-way-to-manage-credentials-in-the-aws-sdks/).
 
-<a id="prev" class="btn btn-basic" href="/docs/">Back</a>
-<a id="next" class="btn btn-primary" href="{% link _docs/structure.md %}">Next Step</a>
+<a id="prev" class="btn btn-basic" href="{% link quick-start.md %}">Back</a>
+<a id="next" class="btn btn-primary" href="{% link _docs/tutorial.md %}">Next Step</a>
 <p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
 

data/docs/_docs/settings.md

@@ -48,7 +48,7 @@ Setting  | Description
 `cluster`  | By convention, the ECS cluster that ufo deploys to matches the `UFO_ENV`. If `UFO=development`, then `ufo ship` deploys to the `development` ECS cluster. This is option overrides this convention.
 `aws_profiles`  | If you have the `AWS_PROFILE` environment variable set, this will ensure that you are deploying the right `UFO_ENV` to the right AWS
 
-### ECS Cluster Convention
+## ECS Cluster Convention
 
 Normally, the ECS cluster defaults to whatever UFO_ENV is set to by [convention]({% link _docs/conventions.md %}).  For example, when `UFO_ENV=production` the ECS Cluster is `production` and when `UFO_ENV=development` the ECS Cluster is `development`.  There are several ways to override this behavior. Let's go through an example:
 
@@ -85,7 +85,7 @@ production:
 ```
 
 
-### AWS_PROFILE support
+## AWS_PROFILE support
 
 An interesting option is `aws_profiles`.  Here's an example:
 
@@ -110,7 +110,7 @@ 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.
 
-<a id="prev" class="btn btn-basic" href="{% link _docs/ufo-help.md %}">Back</a>
+<a id="prev" class="btn btn-basic" href="{% link _docs/structure.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/ufo-env.md %}">Next Step</a>
 <p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
 

data/docs/_docs/structure.md

@@ -30,7 +30,7 @@ File / Directory  | Description
 
 Now that you know where the ufo configurations are located and what they look like.  Let use ufo!
 
-<a id="prev" class="btn btn-basic" href="{% link _docs/install.md %}">Back</a>
-<a id="next" class="btn btn-primary" href="{% link _docs/tutorial.md %}">Next Step</a>
+<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>
 <p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
 

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

@@ -2,7 +2,7 @@
 title: Build Docker
 ---
 
-### Build the Docker Image
+## Build the Docker Image
 
 Let's use the `ufo docker build` command to build the docker image. The command uses the `Dockerfile` in the current project to build the docker image.  You use your own Dockerfile so you have fully control over how you would like the image to be built.  For this tutorial we will continue to use the [tongueroo/hi](https://github.com/tongueroo/hi) app and it's Dockerfile. Let's run the command:
 

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

@@ -52,7 +52,7 @@ The `ufo init` command generated a few starter ufo files for you. The standard d
 
 The explanation of the folders and files were covered in detailed earlier at [Structure]({% link _docs/structure.md %}).
 
-### Settings
+## Settings
 
 Take a look at the `settings.yml` file and notice that it contains some default configuration settings so you do not have to type out these options repeatedly for some of the ufo commands.
 

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

@@ -2,7 +2,7 @@
 title: Deploy One App
 ---
 
-### Step 3 - Ship the Code to ECS
+## Step 3 - Ship the Code to ECS
 
 In this guide we have walked through what ufo does step by step.  First ufo builds the Docker image with `ufo docker build`.  Then it will build and register the ECS task definitions with the `ufo tasks` commands. Now we'll deploy the code to ECS.
 
@@ -68,11 +68,11 @@ Checking the ECS console you should see something like this:
 
 You have successfully shipped a docker image to ECS! 🍾🥂
 
-### Skipping Previous Steps Method
+## Skipping Previous Steps Method
 
 You should notice that `ufo ship` re-built the docker image and re-registered the task definitions.  The `ufo ship` command is designed to run everything in one simple command, so we do not have to manually call the commands in the previous pages: `ufo build` and `ufo tasks`.
 
-If you would like to skip the first 2 steps, then you can use the [ufo deploy]({% link _docs/ufo-deploy.md %}) instead.  The `ufo deploy` command will:
+If you would like to skip the first 2 steps, then you can use the [ufo deploy]({% link _reference/ufo-deploy.md %}) instead.  The `ufo deploy` command will:
 
 1. register the task definition in `.ufo/output/hi-web.json` unmodified
 2. update the ECS service
@@ -95,7 +95,3 @@ 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-ships.md

@@ -16,7 +16,7 @@ ufo ship hi-clock
 
 This would build a new Docker image for each process.  We actually want have the same docker image running on all of these roles.  In this case where we want to use the *same* Docker image for all 3 roles, ufo provides a `ufo ships` command.
 
-### ufo ships
+## ufo ships
 
 ```sh
 ufo ships hi-web hi-worker hi-clock
@@ -33,5 +33,5 @@ ufo ships hi-{web,worker,clock}
 ```
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/tutorial-ufo-ship.md %}">Back</a>
-<a id="next" class="btn btn-primary" href="{% link _docs/commands.md %}">Next Step</a>
+<a id="next" class="btn btn-primary" href="{% link docs.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

@@ -2,7 +2,7 @@
 title: Task Definitions
 ---
 
-### Build the ECS Task Definitions
+## Build the ECS Task Definitions
 
 Now that we have a docker image pushed to a registry we can use that image for ECS.  Ufo takes that image and adds it to an ECS task definition.  This is where ufo is super powerful.  Ufo gives you the power to build and control your ECS task definition easily.
 
@@ -11,7 +11,7 @@ Let's take a look at the 2 files that are used by ufo to build the ECS task defi
 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 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**:
 
@@ -34,7 +34,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:
+The instance variable values are specified in `.ufo/task_definitions.rb` via a DSL.  Here's the file:
 
 **ufo/task_definitions.rb**:
 
@@ -59,7 +59,7 @@ task_definition "hi-worker" do
 end
 ```
 
-### Shared Variables
+## Shared Variables
 
 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:
 
@@ -81,7 +81,7 @@ Ufo has a concept of shared variables, covered in [Shared Variables]({% link _do
 })
 ```
 
-Ufo combines the `main.json.erb` template, `task_definitions.rb` definitions, and variables in the `ufo/variables` folder.  It then generates the raw AWS formatted task definition in the `output` folder.
+Ufo combines the `main.json.erb` template, `task_definitions.rb` definitions, and variables in the `.ufo/variables` folder.  It then generates the raw AWS formatted task definition in the `output` folder.
 
 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.
 
@@ -106,7 +106,7 @@ Task Definitions built in .ufo/output
 $
 ```
 
-Let's take a look at one of the generated files: `ufo/output/hi-web.json`.
+Let's take a look at one of the generated files: `.ufo/output/hi-web.json`.
 
 ```json
 {
@@ -148,7 +148,7 @@ Let's take a look at one of the generated files: `ufo/output/hi-web.json`.
 }
 ```
 
-### Register the ECS Task Definitions
+## 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:
 

data/docs/_docs/tutorial.md

@@ -10,6 +10,6 @@ In the next sections, we'll walk through using ufo in detail. We will ufo-ify a
 
 Let's start!
 
-<a id="prev" class="btn btn-basic" href="{% link _docs/structure.md %}">Back</a>
+<a id="prev" class="btn btn-basic" href="{% link _docs/install.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/tutorial-ufo-init.md %}">Next Step</a>
 <p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>

data/docs/_docs/ufo-env.md

@@ -4,7 +4,7 @@ title: UFO_ENV
 
 Ufo's behavior is controlled by the `UFO_ENV` environment variable.  For example, the `UFO_ENV` variable is used to layer different ufo variable files together to make it easy to specify settings for different environments like production and development.  This is covered thoroughly in the [Variables]({% link _docs/variables.md %}) section.  `UFO_ENV` defaults to `development` when not set.
 
-### Setting UFO_ENV
+## Setting UFO_ENV
 
 The `UFO_ENV` can be set in several ways:
 
@@ -12,13 +12,13 @@ The `UFO_ENV` can be set in several ways:
 2. Exported as an environment variable to your shell - This takes the second highest precedence.
 3. From the `aws_profiles` setting in your `settings.yml` file - This takes the lowest precedence.
 
-### At the CLI Command
+## At the CLI Command
 
 ```sh
 ufo ship hi-web --cluster production
 ```
 
-### As an environment variable
+## As an environment variable
 
 ```sh
 export UFO_ENV=production
@@ -27,9 +27,9 @@ 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:
+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:
 
 ```yaml
 development:

data/docs/_docs/ufo-tasks-register.md

@@ -20,7 +20,3 @@ You can verify that the task definitions have been registered properly by viewin
 
 <img src="/img/tutorials/ecs-console-task-definitions.png" class="doc-photo" />
 
-<a id="prev" class="btn btn-basic" href="{% link _docs/ufo-tasks-build.md %}">Back</a>
-<a id="next" class="btn btn-primary" href="{% link _docs/ufo-help.md %}">Next Step</a>
-<p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
-

data/docs/_docs/variables.md

@@ -2,7 +2,7 @@
 title: Shared Variables
 ---
 
-Often times, you end up using the set of common variables across your task definitions for a project.  Ufo supports a shared variables concept to help with this.  You specify variables files in the `ufo/variables` folder and they are made availale to your `ufo/task_definitions.rb` as well as your `ufo/templates` files.
+Often times, you end up using the set of common variables across your task definitions for a project.  Ufo supports a shared variables concept to help with this.  You specify variables files in the `.ufo/variables` folder and they are made availale to your `.ufo/task_definitions.rb` as well as your `.ufo/templates` files.
 
 For example, given `variables/base.rb`:
 
@@ -13,13 +13,13 @@ 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 declaring them in the `.ufo/task_definitions.rb` file.  Variables are automatically made available to all templates and the `task_definition.rb` file also.
 
-### Layering
+## Layering
 
 Shared variables also support a concept called layering.  The `variables/base.rb` file is treated specially and will always be evaluated.  Additionally, ufo will also evaluate the `variables/[UFO_ENV].rb` according to what UFO_ENV's value is. Thanks to layering, you can easily override variables to suit different environments like `production` or `development`. For example:
 
-`ufo/variables/base.rb`:
+`.ufo/variables/base.rb`:
 
 ```ruby
 @image = helper.full_image_name # includes the git sha tongueroo/hi:ufo-[sha].
@@ -30,7 +30,7 @@ Shared variables also support a concept called layering.  The `variables/base.rb
 
 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:
 
-`ufo/variables/production.rb`:
+`.ufo/variables/production.rb`:
 
 ```ruby
 @environment = helper.env_vars(%Q[
@@ -42,7 +42,7 @@ When `ufo ship` is ran with `UFO_ENV=production` he `variables/production.rb` wi
 When `ufo ship` is ran with `UFO_ENV=development` the `variables/development.rb` will be evaluated and layered on top of the variables defined in `base.rb:
 
 
-`ufo/variables/development.rb`:
+`.ufo/variables/development.rb`:
 
 ```ruby
 @environment = helper.env_vars(%Q[
@@ -51,7 +51,6 @@ When `ufo ship` is ran with `UFO_ENV=development` the `variables/development.rb`
 ])
 ```
 
-
 <a id="prev" class="btn btn-basic" href="{% link _docs/ufo-env.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/helpers.md %}">Next Step</a>
 <p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>