kubernetes-deploy 0.8.0 → 0.8.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: aef7562f456f0a5ad138410f5110fd34ac2231fe
-  data.tar.gz: e421c6d5a6cded2f76ffbb88a677946f54017269
+  metadata.gz: 0a6a0a8232035518d42b8dd709c236df5ee436bb
+  data.tar.gz: b1e8c26dc53fe92a2e22bec894badc46c2e292f4
 SHA512:
-  metadata.gz: b48a5e45f3b8ce91a2d7cff2aa243e052b5bb89836463931993682fa58ceef4878738e19f1dae01cb80019a885eb5d8dfe30cd8b529927f09024e092f296a19e
-  data.tar.gz: 02ae5cc6c72a61bd0fd4b65667bac7dd17c4e6f049252722cb8263d8b9c31240834ff47277355912a87be9be3e49fd1cf13a85d301ca253c0d6bf90e78778a1d
+  metadata.gz: d94033e6774153f24ddbee8fa6e560636ba091cbc3e5a6ac24cab07dc2ac0ed2132d1ce6d5a5a60529e2d309e2589bf42e24c55893a7b48aa034d042afdfcb74
+  data.tar.gz: ef4456ba9e4303a70af71dbf36f63c5a4a4b24c31fa556b34f968dcc59e543c51fe937e4a084b85c4fb659033e8711125d98e637909fa92e89259fbc5a426367

data/README.md

@@ -1,46 +1,143 @@
-# Kubernetes::Deploy
+# kubernetes-deploy [![Build status](https://badge.buildkite.com/0f2d4956d49fbc795f9c17b0a741a6aa9ea532738e5f872ac8.svg?branch=master)](https://buildkite.com/shopify/kubernetes-deploy-gem)
 
-[![Build status](https://badge.buildkite.com/0f2d4956d49fbc795f9c17b0a741a6aa9ea532738e5f872ac8.svg?branch=master)](https://buildkite.com/shopify/kubernetes-deploy-gem)
+`kubernetes-deploy` is a command line tool that helps you ship changes to a Kubernetes namespace and understand the result. At Shopify, we use it within our much-beloved, open-source [Shipit](https://github.com/Shopify/shipit-engine#kubernetes) deployment app.
 
-Deploy script used to manage a Kubernetes application's namespace with [Shipit](https://github.com/Shopify/shipit-engine).
+Why not just use the standard `kubectl apply` mechanism to deploy? It is indeed a fantastic tool; `kubernetes-deploy` uses it under the hood! However, it leaves its users with some burning questions: _What just happened?_ _Did it work?_
 
-## Installation
+Especially in a CI/CD environment, we need a clear, actionable pass/fail result for each deploy. Providing this was the foundational goal of `kubernetes-deploy`, which has grown to support the following core features:
 
-Add this line to your application's Gemfile:
+​:eyes:  Watches the changes you requested to make sure they roll out successfully.
 
-```ruby
-gem 'kubernetes-deploy'
-```
+:interrobang: Provides debug information for changes that failed.
+
+:1234:  Predeploys certain types of resources (e.g. ConfigMap, PersistentVolumeClaim) to make sure the latest version will be available when resources that might consume them (e.g. Deployment) are deployed.
+
+:closed_lock_with_key:  [Creates Kubernetes secrets from encrypted EJSON](#deploying-kubernetes-secrets-from-ejson), which you can safely commit to your repository
+
+​:running: [Runs tasks at the beginning of the deploy](#deploy-time-tasks) using bare pods (example use case: Rails migrations)
+
+This repo also includes related tools for [running tasks](#kubernetes-run) and [restarting deployments](#kubernetes-restart).
+
+![success](screenshots/success.png)
+
+
+
+![missing-secret-fail](screenshots/missing-secret-fail.png)
+
+
+
+--------
+
+
+
+## Table of contents
+
+**KUBERNETES-DEPLOY**
+* [Prerequisites](#prerequisites)
+* [Installation](#installation)
+* [Usage](#usage)
+  * [Using templates and variables](#using-templates-and-variables)
+  * [Running tasks at the beginning of a deploy](#running-tasks-at-the-beginning-of-a-deploy)
+  * [Deploying Kubernetes secrets (from EJSON)](#deploying-kubernetes-secrets-from-ejson)
+
+**KUBERNETES-RESTART**
+* [Usage](#usage-1)
+
+**KUBERNETES-RUN**
+* [Prerequisites](#prerequisites-1)
+* [Usage](#usage-2)
+
+**DEVELOPMENT**
+* [Setup](#setup)
+* [Running the test suite locally](#running-the-test-suite-locally)
+* [Releasing a new version (Shopify employees)](#releasing-a-new-version-shopify-employees)
+* [CI (Shopify employees)](#ci-shopify-employees)
+* [CI (External contributors)](#ci-external-contributors)
+
+**CONTRIBUTING**
+* [Contributing](#contributing)
+* [License](#license)
+
+
+----------
+
+
+
+## Prerequisites
 
-And then execute:
+* Your cluster must be running Kubernetes v1.6.0 or higher
+* Each app must have a deploy directory containing its Kubernetes templates (see [Templates](#templates))
+* You must remove the` kubectl.kubernetes.io/last-applied-configuration` annotation from any resources in the namespace that are not included in your deploy directory. This annotation is added automatically when you create resources with `kubectl apply`. `kubernetes-deploy` will prune any resources that have this annotation and are not in the deploy directory.**
+* Each app managed by `kubernetes-deploy` must have its own exclusive Kubernetes namespace.**
+
+
+**This requirement can be bypassed with the `--no-prune` option, but it is not recommended.
+
+## Installation
+
+1. [Install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-binary-via-curl) (requires v1.6.0 or higher) and make sure it is available in your $PATH
+2. Set up your [kubeconfig file](https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for access to your cluster(s).
+3. `gem install kubernetes-deploy`
 
-    $ bundle
 
-Or install it yourself as:
 
-    $ gem install kubernetes-deploy
 
 ## Usage
 
-`kubernetes-deploy <app's namespace> <kube context> --template-dir=DIR`
+`kubernetes-deploy <app's namespace> <kube context>`
 
-Requirements:
+*Environment variables:*
 
- - kubectl 1.6.0+ binary must be available in your path
- - `ENV['KUBECONFIG']` must point to a valid kubeconfig file that includes the context you want to deploy to
- - The target namespace must already exist in the target context
- - `ENV['GOOGLE_APPLICATION_CREDENTIALS']` must point to the credentials for an authenticated service account if your user's auth provider is GCP
- - `ENV['ENVIRONMENT']` must be set to use the default template path (`config/deploy/$ENVIRONMENT`) in the absence of the `--template-dir=DIR` option
+- `$REVISION` **(required)**: the SHA of the commit you are deploying. Will be exposed to your ERB templates as `current_sha`.
+- `$KUBECONFIG`  **(required)**: points to a valid kubeconfig file that includes the context you want to deploy to
+- `$ENVIRONMENT`: used to set the deploy directory to `config/deploy/$ENVIRONMENT`. You can use the `--template-dir=DIR` option instead if you prefer (**one or the other is required**).
+- `$GOOGLE_APPLICATION_CREDENTIALS`: points to the credentials for an authenticated service account (required if your kubeconfig `user`'s auth provider is GCP)
 
-The tool also provides a task for restarting all of the pods in one or more deployments.
-It triggers the restart by touching the `RESTARTED_AT` environment variable in the deployment's podSpec.
-The rollout strategy defined for each deployment will be respected by the restart.
 
-The following command will restart all pods in the `web` and `jobs` deployments:
+*Options:*
+
+- `--bindings=BINDINGS`: Makes additional variables available to your ERB templates. For example, `kubernetes-deploy my-app cluster1 --bindings=color=blue,size=large` will expose `color` and `size`.
+- `--verbose-log-prefix`: Prefixes each log line with `[#{context}][#{namespace}][#{severity}][#{datetime}]` instead of just `[#{severity}][#{datetime}]`. Useful if you're running multiple concurrent deploys in Shipit.
+- `--allow-protected-ns`: Enables you to deploy to `default`, `kube-system` or `kube-public` if you really know what you're doing. Must be used with `--no-prune` (pruning a protected namespace cannot be enabled).
+- `--no-prune`: Skips pruning of resources that are no longer in your Kubernetes template set. Not recommended, as it allows your namespace to accumulate cruft that is not reflected in your deploy directory.
+- `--skip-wait`: Verifies the result of predeployed resources only. Declares success immediately after the bulk `kubectl apply` operation. Not recommended, as it skips a huge part of the value of this tool.
+
+
+
+
+
+### Using templates and variables
+
+Each app's templates are expected to be stored in a single directory. If this is not the case, you can create a directory containing symlinks to the templates. The recommended location for app's deploy directory is `{app root}/config/deploy/{env}`, but this is completely configurable.
+
+All templates must be YAML formatted. You can also use ERB. The following local variables will be available to your ERB templates by default:
+
+* `current_sha`: The value of `$REVISION`
+* `deployment_id`:  A randomly generated identifier for the deploy. Useful for creating unique names for task-runner pods (e.g. a pod that runs rails migrations at the beginning of deploys).
+
+You can add additional variables using the `--bindings=BINDINGS` option. For example, `kubernetes-deploy my-app cluster1 --bindings=color=blue,size=large` will expose `color` and `size` in your templates.
+
+
+
+### Running tasks at the beginning of a deploy
+
+To run a task in your cluster at the beginning of every deploy, simply include a `Pod` template in your deploy directory. `kubernetes-deploy` will first deploy any `ConfigMap` and `PersistentVolumeClaim` resources in your template set, followed by any such pods. If the command run by one of these pods fails (i.e. exits with a non-zero status), the overall deploy will fail at this step (no other resources will be deployed).
+
+*Requirements:*
+
+* The pod's name should include `<%= deployment_id %>` to ensure that a unique name will be used on every deploy (the deploy will fail if a pod with the same name already exists).
+* The pod's `spec.restartPolicy` must be set to `Never` so that it will be run exactly once. We'll fail the deploy if that run exits with a non-zero status.
+* The pod's `spec.activeDeadlineSeconds` should be set to a reasonable value for the performed task (not required, but highly recommended)
+
+A simple example can be found in the test fixtures: test/fixtures/hello-cloud/unmanaged-pod.yml.erb.
+
+The logs of all pods run in this way will be printed inline.
+
+![migrate-logs](screenshots/migrate-logs.png)
 
-`kubernetes-restart <kube namespace> <kube context> --deployments=web,jobs`
 
-### Deploying Kubernetes secrets
+
+### Deploying Kubernetes secrets (from EJSON)
 
 **Note: If you're a Shopify employee using our cloud platform, this setup has already been done for you. Please consult the CloudPlatform User Guide for usage instructions.**
 
@@ -91,59 +188,130 @@ Since their data is only base64 encoded, Kubernetes secrets should not be commit
   }
 ```
 
-### Running one off tasks
 
-To trigger a one-off job such as a rake task _outside_ of a deploy, use the following command:
 
-`kubernetes-run <kube namespace> <kube context> <arguments> --entrypoint=/bin/bash`
+# kubernetes-restart
+
+`kubernetes-restart` is a tool for restarting all of the pods in one or more deployments. It triggers the restart by touching the `RESTARTED_AT` environment variable in the deployment's podSpec. The rollout strategy defined for each deployment will be respected by the restart.
+
+
+
+## Usage
+
+The following command will restart all pods in the `web` and `jobs` deployments:
+
+`kubernetes-restart <kube namespace> <kube context> --deployments=web,jobs`
+
+
 
-This command assumes that you've already deployed a `PodTemplate` named `task-runner-template`, which contains a full pod specification in its `data`. The pod specification in turn must have a container named `task-runner`. Based on this specification `kubernetes-run` will create a new pod with the entrypoint of the task-runner container overriden with the supplied arguments.
+# kubernetes-run
 
-#### Creating a PodTemplate
+`kubernetes-run` is a tool for triggering a one-off job, such as a rake task, _outside_ of a deploy.
 
-The [`PodTemplate`](https://kubernetes.io/docs/api-reference/v1.6/#podtemplate-v1-core) object should have a field `template` containing a `Pod` specification which does not include the `apiVersion` or `kind` parameters. An example is provided in this repo in `test/fixtures/hello-cloud/template-runner.yml`.
 
-#### Providing multiple different task-runner configurations
 
-If your application requires task runner templates you can specify which template to use by using the `--template` option. All templates are expected to provide a container called `task-runner`.
+## Prerequisites
 
-#### Specifying environment variables for the container
+* You've already deployed a [`PodTemplate`](https://kubernetes.io/docs/api-reference/v1.6/#podtemplate-v1-core) object with field `template` containing a `Pod` specification that does not include the `apiVersion` or `kind` parameters. An example is provided in this repo in `test/fixtures/hello-cloud/template-runner.yml`.
+* The `Pod` specification in that template has a container named `task-runner`.
 
-If you also need to specify environment variables on top of the arguments, you can specify the `--env-vars` flag which accepts a comma separated list of environment variables like so: `--env-vars="ENV=VAL,ENV2=VAL"`
+Based on this specification `kubernetes-run` will create a new pod with the entrypoint of the `task-runner ` container overridden with the supplied arguments.
 
 
-## Development
 
-After checking out the repo, run `bin/setup` to install dependencies. You currently need to [manually install kubectl version 1.6.0 or higher](https://kubernetes.io/docs/user-guide/prereqs/) as well if you don't already have it.
+## Usage
+
+`kubernetes-run <kube namespace> <kube context> <arguments> --entrypoint=/bin/bash`
+
+*Options:*
+
+* `--template=TEMPLATE`:  Specifies the name of the PodTemplate to use (default is `task-runner-template` if this option is not set).
+* `--env-vars=ENV_VARS`: Accepts a comma separated list of environment variables to be added to the pod template. For example, `--env-vars="ENV=VAL,ENV2=VAL2"` will make `ENV` and `ENV2` available to the container.
+
+
 
-To run the tests:
 
-* [Install minikube](https://kubernetes.io/docs/getting-started-guides/minikube/#installation)
-* Start minikube (`minikube start [options]`)
-* Make sure you have a context named "minikube" in your kubeconfig. Minikube adds this context for you when you run `minikube start`; please do not rename it. You can check for it using `kubectl config get-contexts`.
-* Run `bundle exec rake test`
+
+# Development
+
+## Setup
+
+1. [Install kubectl version 1.6.0 or higher](https://kubernetes.io/docs/user-guide/prereqs/) and make sure it is in your path
+2. [Install minikube](https://kubernetes.io/docs/getting-started-guides/minikube/#installation) (required to run the test suite)
+3. Check out the repo
+4. Run `bin/setup` to install dependencies
 
 To install this gem onto your local machine, run `bundle exec rake install`.
 
-To release a new version:
 
-* Update the version number in `version.rb`
-* Tag the version with `git tag vx.y.z && git push --tags`
-* A Shopify employee can use the [Shipit Stack](https://shipit.shopify.io/shopify/kubernetes-deploy/rubygems) to build the `.gem` file and upload to [rubygems.org](https://rubygems.org/gems/kubernetes-deploy).
 
-## CI
+## Running the test suite locally
+
+1. Start [minikube](https://kubernetes.io/docs/getting-started-guides/minikube/#installation) (`minikube start [options]`)
+2. Make sure you have a context named "minikube" in your kubeconfig. Minikube adds this context for you when you run `minikube start`; please do not rename it. You can check for it using `kubectl config get-contexts`.
+3. Run `bundle exec rake test`
+
+
 
-Buildkite will build branches as you're working on them, but as soon as you create a PR it will stop building new commits from that branch because we disabled PR builds for security reasons.
-As a Shopify employee, you can manually trigger the PR build from the Buildkite UI (just specify the branch, SHA is not required):
+To see the full-color output of a specific integration test, you can use `PRINT_LOGS=1 bundle exec ruby -I test test/integration/kubernetes_deploy_test.rb -n/test_name/`.
+
+
+
+![test-output](screenshots/test-output.png)
+
+
+
+## Releasing a new version (Shopify employees)
+
+1. Update the version number in `version.rb` and commit that change alone to master.
+2. Tag the version with `git tag vx.y.z && git push --tags`
+3. Use the [Shipit Stack](https://shipit.shopify.io/shopify/kubernetes-deploy/rubygems) to build the `.gem` file and upload to [rubygems.org](https://rubygems.org/gems/kubernetes-deploy).
+
+If Shipit fails with `You need to create the v0.7.9 tag first.` even though you're sure you've already pushed that tag, go to `Settings` > `Resynchronize this stack` > `Clear git cache`.
+
+
+
+## CI (Shopify employees)
+
+Buildkite will build branches as you're working on them, but as soon as you create a PR it will stop building new commits from that branch because we disabled PR builds for security reasons. You can manually trigger the PR build from the [Buildkite UI](https://buildkite.com/shopify/kubernetes-deploy-gem) (just specify the branch; SHA is not required).
 
 <img width="464" alt="screen shot 2017-02-21 at 10 55 33" src="https://cloud.githubusercontent.com/assets/522155/23172610/52771a3a-f824-11e6-8c8e-3d59c45e7ff8.png">
 
 
-## Contributing
 
-Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/kubernetes-deploy.
+## CI (External contributors)
+
+Please make sure you run the tests locally before submitting your PR (see [Running the test suite locally](#running-the-test-suite-locally)). A Shopify employee will trigger CI for you after reviewing your PR.
+
+
+
+# Contributing
+
+Bug reports and pull requests are welcome on GitHub at https://github.com/Shopify/kubernetes-deploy.
+
+Contributions to help us support additional resource types or increase the sophistication of our success heuristics for an existing type are especially encouraged! (See tips below)
+
+
+
+### Contributing a new resource type
+
+The list of fully supported types is effectively the list of classes found in `lib/kubernetes-deploy/kubernetes_resource/`.
+
+This gem uses subclasses of `KubernetesResource` to implement custom success/failure detection logic for each resource type. If no subclass exists for a type you're deploying, the gem simply assumes `kubectl apply` succeeded (and prints a warning about this assumption). We're always looking to support more types! Here are the basic steps for contributing a new one:
+
+1. Create a the file for your type in `lib/kubernetes-deploy/kubernetes_resource/`
+2. Create a new class that inherits from `KubernetesResource`. Minimally, it should implement the following methods:
+    * `sync` -- gather/update the data you'll need to determine `deploy_succeeded?` and `deploy_failed?`
+    * `deploy_succeeded?`
+    * `deploy_failed?`
+    * `exists?`
+3. Adjust the `TIMEOUT` constant to an appropriate value for this type.
+4. Add the a basic example of the type to the hello-cloud [fixture set](https://github.com/Shopify/kubernetes-deploy/tree/master/test/fixtures/hello-cloud) and appropriate assertions to `#assert_all_up` in [`hello_cloud.rb`](https://github.com/Shopify/kubernetes-deploy/blob/master/test/helpers/fixture_sets/hello_cloud.rb). This will get you coverage in several existing tests, such as `test_full_hello_cloud_set_deploy_succeeds`.
+5. Add tests for any edge cases you foresee.
+
+
 
 
-## License
+# License
 
 The gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).

data/exe/kubernetes-deploy

@@ -2,7 +2,6 @@
 # frozen_string_literal: true
 
 require 'kubernetes-deploy'
-
 require 'optparse'
 
 skip_wait = false

data/kubernetes-deploy.gemspec

@@ -25,6 +25,7 @@ Gem::Specification.new do |spec|
   spec.add_dependency "googleauth", ">= 0.5"
   spec.add_dependency "ejson", "1.0.1"
   spec.add_dependency "colorize", "~> 0.8"
+  spec.add_dependency "statsd-instrument", "~> 2.1"
 
   spec.add_development_dependency "bundler"
   spec.add_development_dependency "rake", "~> 10.0"

data/lib/kubernetes-deploy.rb

@@ -13,6 +13,8 @@ require 'colorized_string'
 require 'kubernetes-deploy/errors'
 require 'kubernetes-deploy/formatted_logger'
 require 'kubernetes-deploy/runner'
+require 'kubernetes-deploy/statsd'
 
 module KubernetesDeploy
+  KubernetesDeploy::StatsD.build
 end

data/lib/kubernetes-deploy/kubernetes_resource.rb

@@ -54,6 +54,7 @@ module KubernetesDeploy
       @context = context
       @logger = logger
       @definition = definition
+      @statsd_report_done = false
     end
 
     def id
@@ -184,6 +185,24 @@ module KubernetesDeploy
       @kubectl ||= Kubectl.new(namespace: @namespace, context: @context, logger: @logger, log_failure_by_default: false)
     end
 
+    def report_status_to_statsd(watch_time)
+      unless @statsd_report_done
+        status = if deploy_failed?
+          "failure"
+        elsif deploy_timed_out?
+          "timeout"
+        elsif deploy_succeeded?
+          "success"
+        else
+          "unknown"
+        end
+        tags = %W(namespace:#{namespace} resource:#{id} type:#{type} sha:#{ENV['REVISION']} status:#{status})
+        ::StatsD.measure('resource.duration', watch_time * 1000, tags: tags)
+        ::StatsD.increment('resource.status', 1, tags: tags)
+        @statsd_report_done = true
+      end
+    end
+
     class Event
       EVENT_SEPARATOR = "ENDEVENT--BEGINEVENT"
       FIELD_SEPARATOR = "ENDFIELD--BEGINFIELD"

data/lib/kubernetes-deploy/resource_watcher.rb

@@ -39,6 +39,8 @@ module KubernetesDeploy
     private
 
     def report_what_just_happened(resources, watch_time)
+      resources.each { |r| r.report_status_to_statsd(watch_time) }
+
       new_successes, new_failures = resources.partition(&:deploy_succeeded?)
       new_failures.each do |resource|
         if resource.deploy_failed?

data/lib/kubernetes-deploy/runner.rb

@@ -79,6 +79,7 @@ module KubernetesDeploy
     end
 
     def run(verify_result: true, allow_protected_ns: false, prune: true)
+      start = Time.now.utc
       @logger.reset
 
       @logger.phase_heading("Initializing deploy")
@@ -104,7 +105,9 @@ module KubernetesDeploy
 
       if deploy_has_priority_resources?(resources)
         @logger.phase_heading("Predeploying priority resources")
-        predeploy_priority_resources(resources)
+        ::StatsD.measure('duration.priority_resources', tags: statsd_tags) do
+          predeploy_priority_resources(resources)
+        end
       end
 
       @logger.phase_heading("Deploying all resources")
@@ -113,7 +116,9 @@ module KubernetesDeploy
       end
 
       if verify_result
-        deploy_resources(resources, prune: prune, verify: true)
+        ::StatsD.measure('duration.normal_resources', tags: statsd_tags) do
+          deploy_resources(resources, prune: prune, verify: true)
+        end
         record_statuses(resources)
         success = resources.all?(&:deploy_succeeded?)
       else
@@ -131,6 +136,7 @@ module KubernetesDeploy
       success = false
     ensure
       @logger.print_summary(success)
+      ::StatsD.measure('duration.total', (Time.now.utc - start) * 1000.0, tags: statsd_tags)
       success
     end
 
@@ -433,5 +439,9 @@ module KubernetesDeploy
     def kubectl
       @kubectl ||= Kubectl.new(namespace: @namespace, context: @context, logger: @logger, log_failure_by_default: true)
     end
+
+    def statsd_tags
+      %W(namespace:#{@namespace} sha:#{@current_sha})
+    end
   end
 end

data/lib/kubernetes-deploy/statsd.rb

@@ -0,0 +1,22 @@
+# frozen_string_literal: true
+require 'statsd-instrument'
+require 'logger'
+
+module KubernetesDeploy
+  class StatsD
+    def self.build
+      ::StatsD.default_sample_rate = 1.0
+      ::StatsD.prefix = "KubernetesDeploy"
+
+      if ENV['STATSD_DEV'].present?
+        ::StatsD.backend = ::StatsD::Instrument::Backends::LoggerBackend.new(Logger.new($stderr))
+      elsif ENV['STATSD_ADDR'].present?
+        statsd_impl = ENV['STATSD_IMPLEMENTATION'].empty? ? "datadog" : ENV['STATSD_IMPLEMENTATION']
+        ::StatsD.backend = ::StatsD::Instrument::Backends::UDPBackend.new(ENV['STATSD_ADDR'], statsd_impl)
+      else
+        ::StatsD.backend = ::StatsD::Instrument::Backends::NullBackend.new
+      end
+      ::StatsD.backend
+    end
+  end
+end

data/lib/kubernetes-deploy/version.rb

@@ -1,3 +1,3 @@
 module KubernetesDeploy
-  VERSION = "0.8.0"
+  VERSION = "0.8.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: kubernetes-deploy
 version: !ruby/object:Gem::Version
-  version: 0.8.0
+  version: 0.8.1
 platform: ruby
 authors:
 - Katrina Verey
@@ -9,7 +9,7 @@ authors:
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2017-07-06 00:00:00.000000000 Z
+date: 2017-07-11 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activesupport
@@ -81,6 +81,20 @@ dependencies:
     - - "~>"
       - !ruby/object:Gem::Version
         version: '0.8'
+- !ruby/object:Gem::Dependency
+  name: statsd-instrument
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '2.1'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '2.1'
 - !ruby/object:Gem::Dependency
   name: bundler
   requirement: !ruby/object:Gem::Requirement
@@ -212,7 +226,12 @@ files:
 - lib/kubernetes-deploy/restart_task.rb
 - lib/kubernetes-deploy/runner.rb
 - lib/kubernetes-deploy/runner_task.rb
+- lib/kubernetes-deploy/statsd.rb
 - lib/kubernetes-deploy/version.rb
+- screenshots/migrate-logs.png
+- screenshots/missing-secret-fail.png
+- screenshots/success.png
+- screenshots/test-output.png
 homepage: https://github.com/Shopify/kubernetes-deploy
 licenses:
 - MIT