kubernetes-deploy 0.29.0 → 1.0.0.pre.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: a0641a291f2f01c007051cf5001bc97ecb9216b55e7204d954c920083e0d303a
-  data.tar.gz: 2c2415cfd94a63f046b94e90c943a7f9e01a46207833c1d5d2a498ceeb1ff333
+  metadata.gz: 5f64c627d9b1e7c3c2ba432e334dd7c9df8f9ee9e9d313be3ea1172a24262d45
+  data.tar.gz: e0de3c34b36943fce44584081c41eb7eb9fbaacb6d30395e851b6f2074c7e8bf
 SHA512:
-  metadata.gz: 18a4e86f4f144dfa23ebc191b7d06382605ada3b050e8e1c9e717cbc9db981f16b419fb27a342f4e1267663f8f82fb12bcebfe0697c9ac4ac40c15108ab73072
-  data.tar.gz: 314bdadd3d8f864895c13e81193845f4632fa46dc23550f12955a5ffe7a7b15ed3df1e12d769d5aefdb8ee4b7e5c3e3e13d5f8378f5c828a2e4bf3c04db8c56c
+  metadata.gz: 4c8406aabda6be3be66c254c01024e4ced5d2fb068755baa342a6152426d312fdd21d379e858bc52a5dd609fd2788074cdb46e3d23210b06457c779101a4a85d
+  data.tar.gz: f8ebafe3d74f8467369cba698b0efd8e833596a420a27dd576f16fe8b990a9232c56cc29579e212879d738da4a8b1c30b6f1a14cd8cd7f2390d1a968dd7de775

data/.buildkite/pipeline.nightly.yml

@@ -1,4 +1,11 @@
 steps:
+  - name: 'Run Test Suite (:kubernetes: 1.16-latest)'
+    command: bin/ci
+    agents:
+      queue: k8s-ci
+    env:
+      LOGGING_LEVEL: 4
+      KUBERNETES_VERSION: v1.16-latest
   - name: 'Run Test Suite (:kubernetes: 1.15-latest)'
     command: bin/ci
     agents:

data/.rubocop.yml

@@ -3,15 +3,3 @@ inherit_from:
 
 AllCops:
   TargetRubyVersion: 2.4
-
-Naming/FileName:
-  Enabled: true
-  Exclude:
-    - lib/kubernetes-deploy.rb
-
-Sorbet/ConstantsFromStrings:
-  Enabled: false
-
-Layout/Tab:
-  Exclude:
-    - test/integration/kubernetes_deploy_test.rb

data/.shopify-build/{kubernetes-deploy.yml → krane.yml}

@@ -6,9 +6,15 @@ steps:
   - label: Lint
     timeout: 5m
     run:
+      - bundle: ~
       - bundle exec rubocop
-    dependencies:
-      - bundler
+  - label: 'Run Test Suite (:kubernetes: 1.16.12)'
+    command: bin/ci
+    agents:
+      queue: k8s-ci
+    env:
+      LOGGING_LEVEL: "4"
+      KUBERNETES_VERSION: v1.16.12
   - label: 'Run Test Suite (:kubernetes: 1.15-latest)'
     command: bin/ci
     agents:

data/1.0-Upgrade.md

@@ -0,0 +1,109 @@
+# kubernetes-deploy 0.31.1 -> krane 1.0.0 migration guide
+
+**THIS MIGRATION GUIDE IS A WORK IN PROGRESS. THINGS CAN STILL CHANGE BEFORE 1.0.0**
+
+`kubernetes-deploy` was renamed `krane` when version 1.0.0 was released. Version 1.0.0 introduced [new features and breaking changes](CHANGELOG.md). This guide will help you transition to version 1.0.0 as smoothly as possible.
+
+**TL;DR**:
+* The command-line interface was redesigned; alongside the name change there are breaking changes in several flags.
+* There are breaking changes in the public API (such as the renaming of the `KubernetesDeploy` namespace to `Krane`, and the change in default values for different arguments of the public interface).
+* StatsD metrics will now be generated with the `krane` prefix.
+* `krane deploy` now considers all namespaced resources eligible for pruning, including
+custom resources. See [blacklist](https://github.com/Shopify/kubernetes-deploy/blob/master/lib/krane/cluster_resource_discovery.rb#L20) for exceptions.
+* `kubernetes-deploy` (now `krane deploy`) / `DeployTask` can no longer deploy global (non-namespaced) resources. A new command called `krane global-deploy` and a related class called `GlobalDeployTask` were added to replace that feature.
+* If you attempt to install two gems that have conflicting executables, `gem install` will warn you but the most recently installed one will win.
+
+## Public API changes
+
+The only breaking change in the public API (so far) is the renaming of the `KubernetesDeploy` namespace to `Krane`. Otherwise, the APIs of the major public classes (`DeployTask`, `RenderTask`, `RunnerTask`, and `RestartTask`) have not changed between 0.31.1 and 1.0.0. If you're curious about this API, check the comment-based docs on these classes or the [rendered documentation at RubyGems.org](https://www.rubydoc.info/gems/kubernetes-deploy/1.0.0/KubernetesDeploy/DeployTask).
+
+## Command-line interface changes
+
+Old command | New command
+--- | ---
+`kubernetes-deploy` | `krane deploy`
+`kubernetes-deploy -v` | `krane version`
+`kubernetes-render` | `krane render`
+`kubernetes-run` | `krane run`
+`kubernetes-restart` | `krane restart`
+`[kubernetes-deploy with global resources in templates]` | `krane global-deploy`
+
+### Flag changes
+
+The following tables provide a mapping of the flags previously supported in `kubernetes-deploy` and their new version in `krane` (if applicable).
+
+Important: you can't repeat flags. If you need to provide multiple arguments for a flag, use a space-separated list (e.g. `-f file1.yml file2.yml`) unless specified otherwise.
+
+#### krane deploy
+
+Old flag | New flag | Comments
+--- | --- | ---
+--bindings=BINDINGS | --bindings=BINDINGS |
+--skip-wait | --verify-result=true |
+--allow-protected-ns | --protected-namespaces=default,kube-system,kube-public | Added the ability to specify which namespaces are protected
+--no-prune | --prune=true |
+--template-dir | -f, --filename | Makes all krane commands accept this argument, which is now required for the deploy task
+--verbose-log-prefix | --verbose-log-prefix |
+--max-watch-seconds=seconds | --global-timeout=300s | Changed flag name and default value to be a duration (expressed using strings like "300s" or "1h")
+--selector | --selector |
+-h, --help | -h, --help |
+-v, --version | [none] | Replaced with `krane version`
+$ENVIRONMENT | [none] | Dropped in favour of `-f`
+$REVISION | --current-sha | The environment variable REVISION was dropped in favour of an explicit flag
+[none] | --render-erb | **Important:** the new CLI doesn't render ERB by default
+[none] | --stdin | Allow template filenames given from stdin stream
+
+#### krane restart
+
+Old flag | New flag | Comments
+--- | --- | ---
+--deployments=LIST | --deployments=LIST |
+--max-watch-seconds=seconds | --global-timeout=300s | Changed flag name and default value to be a duration (expressed using strings like "300s" or "1h")
+[none] | --verify-result=true | Defines whether it should wait for results or exit immediately after validation
+
+#### krane run
+
+Old flag | New flag | Comments
+--- | --- | ---
+--skip-wait | --verify-result=true |
+--max-watch-seconds=seconds | --global-timeout=300s | Changed flag name and default value to be a duration (expressed using strings like "300s" or "1h")
+--entrypoint | --command | Changed flag name to make its purpose clearer
+--template | --template | Changed to be required
+[it is positional now] | --arguments | Optional flag, as `command` or the template might already specify the required arguments
+--env-vars=ENV_VARS | --env-vars=ENV_VARS |
+
+#### krane render
+
+Old flag | New flag | Comments
+--- | --- | ---
+--bindings=BINDINGS | --bindings=BINDINGS |
+--template-dir | -f, --filename | Changed to be more aligned with `kubectl apply` and other krane tasks
+$REVISION | --current-sha | The environment variable REVISION was dropped in favour of an explicit flag
+[none] | --stdin | Allow template filenames given from stdin stream
+
+## Running `kubernetes-deploy` and `krane` side by side
+
+If you attempt to install two gems that have conflicting executables (as is the case here), `gem install` will warn you but the most recently installed one will win. This means that you can run both `kubernetes-deploy` 0.31.1 and `krane` 1.0.0 side by side by doing:
+
+```bash
+gem install kubernetes-deploy -v 0.31.1
+gem install -f krane -v 1.0.0
+```
+
+This can help you incrementally port scripts that use the old CLI to the new one.
+
+## New task: `krane global-deploy`
+
+`krane global-deploy` (accessible through the Ruby API as `Krane::GlobalDeployTask`) can deploy global (non-namespaced) resources such as `PersistentVolume`, `Namespace`, and `CustomResourceDefinition`. Its interface is very similar to `krane deploy`. Example usage:
+
+```bash
+$ cat my-template.yml
+    apiVersion: storage.k8s.io/v1
+    kind: StorageClass
+    metadata:
+      name: testing-storage-class
+      labels:
+        app: krane
+    provisioner: kubernetes.io/no-provisioner
+$ krane global-deploy my-k8s-context -f my-template.yml --selector app=krane
+```

data/CHANGELOG.md

@@ -3,11 +3,71 @@
 *Important!*
 - The next release will be 1.0.0, which means that master will contain breaking changes.
 
+## 1.0.0.pre.2
+
+*Enhancements*
+- Relax thor version requirement. ([#731](https://github.com/Shopify/krane/pull/731))
+- Relax googleauth restriction. ([#731](https://github.com/Shopify/krane/pull/731))
+
+## 1.0.0.pre.1
+
+*Important!*
+
+- This is the final release of KubernetesDeploy. Version 1.0.0 will be released
+under the name `Krane`. We've added a migration guide to help make it easier to migrate.
+([#607](https://github.com/Shopify/kubernetes-deploy/pull/607))
+
+*Enhancements*
+- (beta) `krane deploy` will now consider all namespaced resources eligible for pruning
+and does not respect the `krane.shopify.io/prunable` annotation. This adds 5 additional
+types: Endpoints, Event, LimitRange, ReplicationController, and Lease.
+ ([#616](https://github.com/Shopify/kubernetes-deploy/pull/616)
+
+- (beta) Added the `--stdin` flag to `krane deploy|global-deploy|render` to read resources from stdin. ([#630](https://github.com/Shopify/kubernetes-deploy/pull/630))
+
+## 0.31.1
+
+*Bug Fixes*
+- Fix a scoping issue of ClusterResourceDiscovery where it was not visible to kubernetes-run, causing a crash. ([#624](https://github.com/Shopify/kubernetes-deploy/pull/624))
+
+## 0.31.0
+
+*Enhancements*
+- (alpha) Add a new krane global-deploy task for deploying global resources. Note that global pruning is turned on by default ([#602](https://github.com/Shopify/kubernetes-deploy/pull/602) and [#612](https://github.com/Shopify/kubernetes-deploy/pull/612))
+- Add support for deploying resources that use `generateName` ([#608](https://github.com/Shopify/kubernetes-deploy/pull/608))
+- ENV["REVISION"] is not transparently passed into krane. Instead, you must now use the `--current-sha` flag to set the `current_sha` ERB binding in your templates. Note that kubernetes-deploy, _but not krane_, can still use ENV["REVISION"] as a fallback if `--current-sha` is not provided. ([#613](https://github.com/Shopify/kubernetes-deploy/pull/613))
+
+*Bug Fixes*
+- `krane deploy` can accept multiple filenames with `-f` flag ([#606](https://github.com/Shopify/kubernetes-deploy/pull/606))
+- Ensure DaemonSet status has converged with pod statuses before reporting rollout success ([#617](https://github.com/Shopify/kubernetes-deploy/pull/617))
+
+*Other*
+- Update references from using `kubernetes-deploy` to `krane` in preparation for 1.0 release ([#585](https://github.com/Shopify/kubernetes-deploy/pull/585))
+- Refactor StatsD usage so we can depend on the latest version again. ([#594](https://github.com/Shopify/kubernetes-deploy/pull/594))
+
+## 0.30.0
+
+*Enhancements*
+- **[Breaking change]** Added PersistentVolumeClaim to the prune whitelist. ([#573](https://github.com/Shopify/kubernetes-deploy/pull/573))
+  * To see what resources may be affected, run `kubectl get pvc -o jsonpath='{ range .items[*] }{.metadata.namespace}{ "\t" }{.metadata.name}{ "\t" }{.metadata.annotations}{ "\n" }{ end }' --all-namespaces | grep "last-applied"`
+  * To exclude a resource from kubernetes-deploy (and kubectl apply) management, remove the last-applied annotation `kubectl annotate pvc $PVC_NAME kubectl.kubernetes.io/last-applied-configuration-`.
+- Deploying global resources directly from `KubernetesDeploy::DeployTask` is disabled by default. You can use `allow_globals: true` to enable the old behavior. This will be disabled in the Krane version of the task, and a separate purpose-built task will be provided. [#567](https://github.com/Shopify/kubernetes-deploy/pull/567)
+- Deployments to daemonsets now better tolerate autoscaling: nodes that appear mid-deploy aren't required for convergence. [#580](https://github.com/Shopify/kubernetes-deploy/pull/580)
+
+## 0.29.0
+
+*Enhancements*
+- The KubernetesDeploy::RenderTask now supports a template_paths argument. ([#555](https://github.com/Shopify/kubernetes-deploy/pull/546))
+- We no longer hide errors from apply if all sensitive resources have passed server-dry-run validation. ([#570](https://github.com/Shopify/kubernetes-deploy/pull/570))
+
+
 *Bug Fixes*
 - Handle improper duration values more elegantly with better messaging
 
+
 *Other*
 - We now require Ruby 2.4.x since Ruby 2.3 is past EoL.
+- Lock statsd-instrument to 2.3.X due to breaking changes in 2.5.0
 
 ## 0.28.0
 

data/CONTRIBUTING.md

@@ -141,9 +141,9 @@ Using another local cluster:
 2. Put the name of the context you want to use in a file named `.local-context` in the root of this project. For example: `echo "dind" > .local-context`.
 3. Run `bundle exec rake test` (or `dev test` if you work for Shopify).
 
-To make StatsD log what it would have emitted, run a test with `STATSD_DEV=1`.
+To make StatsD log what it would have emitted, run a test with `STATSD_ENV=development`.
 
-To see the full-color output of a specific integration test, you can use `PRINT_LOGS=1`. For example: `PRINT_LOGS=1 bundle exec ruby -I test test/integration/kubernetes_deploy_test.rb -n/test_name/`.
+To see the full-color output of a specific integration test, you can use `PRINT_LOGS=1`. For example: `PRINT_LOGS=1 bundle exec ruby -I test test/integration/krane_deploy_test.rb -n/test_name/`.
 
 
 ![test-output](screenshots/test-output.png)

data/Gemfile

@@ -13,3 +13,4 @@ gem 'codecov', require: false
 gem 'ruby-prof', require: false
 gem 'ruby-prof-flamegraph', require: false
 gem 'minitest-reporters'
+gem 'yard', require: false

data/README.md

@@ -47,6 +47,7 @@ This repo also includes related tools for [running tasks](#kubernetes-run) and [
   * [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)
   * [Deploying custom resources](#deploying-custom-resources)
+* [Walk through the steps of a deployment](#deploy-walkthrough)
 
 **KUBERNETES-RESTART**
 * [Usage](#usage-1)
@@ -267,7 +268,7 @@ To run a task in your cluster at the beginning of every deploy, simply include a
 * 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.
+A simple example can be found in the test fixtures: [test/fixtures/hello-cloud/unmanaged-pod-1.yml.erb](test/fixtures/hello-cloud/unmanaged-pod-1.yml.erb).
 
 The logs of all pods run in this way will be printed inline. If there is only one pod, the logs will be streamed in real-time. If there are multiple, they will be fetched when the pod terminates.
 
@@ -420,6 +421,89 @@ status:
 - `$.status.conditions[?(@.type == "Failed")].status == "True"` means that a failure condition has been fulfilled and the resource is considered failed.
 - Since `error_msg_path` is specified, kubernetes-deploy will log the contents of `$.status.conditions[?(@.type == "Failed")].message`, which in this case is: `resource is failed`.
 
+### Deploy walkthrough
+
+Let's walk through what happens when you run the `deploy` task with [this directory of templates](https://github.com/Shopify/kubernetes-deploy/tree/master/test/fixtures/hello-cloud). You can see this for yourself by running the following command:
+
+```bash
+krane deploy my-namespace my-k8s-cluster -f test/fixtures/hello-cloud --render-erb
+```
+
+As soon as you run this, you'll start seeing some output being streamed to STDERR.
+
+#### Phase 1: Initializing deploy
+
+In this phase, we:
+
+- Perform basic validation to ensure we can proceed with the deploy. This includes checking if we can reach the context, if the context is valid, if the namespace exists within the context, and more. We try to validate as much as we can before trying to ship something because we want to avoid having an incomplete deploy in case of a failure (this is especially important because there's no rollback support).
+- List out all the resources we want to deploy (as described in the template files we used).
+- Render ERB templates and apply partials, if enabled (which is the case for this example). If enabled, we also perform basic validation on the parsed templates.
+
+#### Phase 2: Checking initial resource statuses
+
+In this phase, we check resource statuses. For each resource listed in the previous step, we check Kubernetes for their status; in the first deploy this might show a bunch of items as "Not Found", but for the deploy of a new version, this is an example of what it could look like:
+
+```
+Certificate/services-foo-tls     Exists
+Cloudsql/foo-production          Provisioned
+Deployment/jobs                  3 replicas, 3 updatedReplicas, 3 availableReplicas
+Deployment/web                   3 replicas, 3 updatedReplicas, 3 availableReplicas
+Ingress/web                      Created
+Memcached/foo-production         Healthy
+Pod/db-migrate-856359            Unknown
+Pod/upload-assets-856359         Unknown
+Redis/foo-production             Healthy
+Service/web                      Selects at least 1 pod
+```
+
+The next phase might be either "Predeploying priority resources" (if there's any) or "Deploying all resources". In this example we'll go through the former, as we do have predeployable resources.
+
+#### Phase 3: Predeploying priority resources
+
+This is the first phase that could modify the cluster.
+
+In this phase we predeploy certain types of resources (e.g. `ConfigMap`, `PersistentVolumeClaim`, `Secret`, ...) to make sure the latest version will be available when resources that might consume them (e.g. `Deployment`) are deployed. This phase will be skipped if the templates don't include any resources that would need to be predeployed.
+
+When this runs, we essentially run `kubectl apply` on those templates and periodically check the cluster for the current status of each resource so we can display error or success information. This will look different depending on the type of resource. If you're running the command described above, you should see something like this in the output:
+
+```
+Deploying ConfigMap/hello-cloud-configmap-data (timeout: 30s)
+Successfully deployed in 0.2s: ConfigMap/hello-cloud-configmap-data
+
+Deploying PersistentVolumeClaim/hello-cloud-redis (timeout: 300s)
+Successfully deployed in 3.3s: PersistentVolumeClaim/hello-cloud-redis
+
+Deploying Role/role (timeout: 300s)
+Don't know how to monitor resources of type Role. Assuming Role/role deployed successfully.
+Successfully deployed in 0.2s: Role/role
+```
+
+As you can see, different types of resources might have different timeout values and different success criteria; in some specific cases (such as with Role) we might not know how to confirm success or failure, so we use a higher timeout value and assume it did work.
+
+#### Phase 4: Deploying all resources
+
+In this phase, we:
+
+- Deploy all resources found in the templates, including resources that were predeployed in the previous step (which should be treated as a no-op by Kubernetes). We deploy everything so the pruning logic (described below) doesn't remove any predeployed resources.
+- Prune resources not found in the templates (you can disable this by using `--no-prune`).
+
+Just like in the previous phase, we essentially run `kubectl apply` on those templates and periodically check the cluster for the current status of each resource so we can display error or success information.
+
+If pruning is enabled (which, again, is the default), any [resource which type is listed in `DeployTask.prune_whitelist`](https://github.com/Shopify/kubernetes-deploy/blob/ac42ad7c8c4f6f6b27e706d6642ebe002ca1f683/lib/kubernetes-deploy/deploy_task.rb#L80-L104) that we can find in the namespace but not in the templates will be removed. A particular message about pruning will be printed in the next phase if any resource matches this criteria.
+
+#### Result
+
+The result section will show:
+- A global status: if **all** resources were deployed successfully, this will show up as "SUCCESS"; if at least one resource failed to deploy (due to an error or timeout), this will show up as "FAILURE".
+- A list of resources and their individual status: this will show up as something like "Available", "Created", and "1 replica, 1 availableReplica, 1 readyReplica".
+
+At this point the command also returns a status code:
+- If it was a success, `0`
+- If there was a timeout, `70`
+- If any other failure happened, `1`
+
+**On timeouts**: It's important to notice that a single resource timeout or a global deploy timeout doesn't necessarily mean that the operation failed. Since Kubernetes updates are asynchronous, maybe something was just too slow to return in the configured time; in those cases, usually running the deploy again might work (that should be a no-op for most - if not all - resources).
+
 # 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.
@@ -440,7 +524,7 @@ The following command will restart all pods in the `web` and `jobs` deployments:
 Add the annotation `shipit.shopify.io/restart` to all the deployments you want to target, like this:
 
 ```yaml
-apiVersion: apps/v1beta1
+apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: web

data/dev.yml

@@ -19,8 +19,10 @@ commands:
   test:
     run: bin/test
   tophat:
-    run: PRINT_LOGS=1 bundle exec ruby -I test test/integration/kubernetes_deploy_test.rb -n/${1}/
+    run: PRINT_LOGS=1 bundle exec ruby -I test test/integration/krane_deploy_test.rb -n/${1}/
     desc: Tophat a change by running a test scenario with logging output enabled.
     syntax:
       optional:
         argument: TEST_REGEX
+  doc:
+    run: bundle exec yard doc

data/dev/flamegraph-from-tests

@@ -22,7 +22,7 @@ if [[ -f $PROFILE_FILENAME ]]; then
 fi
 
 echo "Running test(s) with profiling"
-PROFILE=1 bundle exec ruby -I test test/integration/kubernetes_deploy_test.rb -n /$1/ > /dev/null
+PROFILE=1 bundle exec ruby -I test test/integration/krane_deploy_test.rb -n /$1/ > /dev/null
 
 echo "Processing profile"
 cat $PROFILE_FILENAME | perl -w $FLAMEGRAPH_PL --countname=ms --width=1500 --title=$1 > $SVG_FILENAME

data/exe/kubernetes-deploy

@@ -2,9 +2,9 @@
 # frozen_string_literal: true
 
 require 'kubernetes-deploy/deploy_task'
-require 'kubernetes-deploy/options_helper'
-require 'kubernetes-deploy/bindings_parser'
-require 'kubernetes-deploy/label_selector'
+require 'krane/options_helper'
+require 'krane/bindings_parser'
+require 'krane/label_selector'
 
 require 'optparse'
 
@@ -17,9 +17,10 @@ bindings = {}
 verbose_log_prefix = false
 max_watch_seconds = nil
 selector = nil
+current_sha = ENV["REVISION"]
 
 ARGV.options do |opts|
-  parser = KubernetesDeploy::BindingsParser.new
+  parser = Krane::BindingsParser.new
   opts.on("--bindings=BINDINGS", "Expose additional variables to ERB templates " \
     "(format: k1=v1,k2=v2, JSON string or file (JSON or YAML) path prefixed by '@')") { |b| parser.add(b) }
 
@@ -41,7 +42,7 @@ ARGV.options do |opts|
   end
   opts.on("--selector=SELECTOR", "Ensure that all resources in your template dir match the given selector, " \
     "and restrict pruning to deployed resources it selects.  (format: k1=v1,k2=v2)") do |s|
-    selector = KubernetesDeploy::LabelSelector.parse(s)
+    selector = Krane::LabelSelector.parse(s)
   end
 
   opts.on_tail("-h", "--help", "Print this help") do
@@ -49,16 +50,17 @@ ARGV.options do |opts|
     exit
   end
   opts.on_tail("-v", "--version", "Show version") do
-    puts "v#{KubernetesDeploy::VERSION}"
+    puts "v#{Krane::VERSION}"
     exit
   end
+  opts.on("--current-sha=CURRENT_SHA", "Expose SHA `current_sha` in ERB bindings") { |r| current_sha = r }
   opts.parse!
   bindings = parser.parse
 end
 
 namespace = ARGV[0]
 context = ARGV[1]
-logger = KubernetesDeploy::FormattedLogger.build(namespace, context, verbose_prefix: verbose_log_prefix)
+logger = Krane::FormattedLogger.build(namespace, context, verbose_prefix: verbose_log_prefix)
 
 # Deprecation path: this can be removed when --template-dir is fully replaced by -f
 if template_dir && !template_paths.empty?
@@ -68,16 +70,17 @@ end
 template_paths = [template_dir] if template_paths.empty? && template_dir
 
 begin
-  KubernetesDeploy::OptionsHelper.with_processed_template_paths(template_paths) do |paths|
+  Krane::OptionsHelper.with_processed_template_paths(template_paths) do |paths|
     runner = KubernetesDeploy::DeployTask.new(
       namespace: namespace,
       context: context,
-      current_sha: ENV["REVISION"],
+      current_sha: current_sha,
       template_paths: paths,
       bindings: bindings,
       logger: logger,
       max_watch_seconds: max_watch_seconds,
       selector: selector,
+      allow_globals: true
     )
 
     runner.run!(