improvement(cli): remove garden init command

This command is no longer needed and its existence (and name) just
caused confusion.

BREAKING CHANGE:

Any user scripts that run `garden init` will need to be updated to
remove those references.

.circleci/config.yml

@@ -212,9 +212,6 @@ jobs:
       - npm_install
       - configure_kubectl_context
       - *attach-workspace
-      - run:
-          name: Init Garden
-          command: ./garden-service/bin/garden init --root garden-service/test/e2e --logger-type basic
       - run:
           name: Run e2e tests
           # overriding CIRCLE_BUILD_NUM to avoid conflict with other tests

docs/guides/in-cluster-building.md

@@ -66,11 +66,7 @@ In this mode, builds are executed as follows:
 2. A build is triggered in the Docker daemon.
 3. The built image is pushed to an in-cluster registry (which is automatically installed), which makes it available to the cluster.
 
-After enabling this mode (we currently still default to the `local` mode), you will need to run `garden init` for each
-applicable environment, in order to install the
-required cluster-wide services. Those services include the Docker daemon itself, as well as an image registry,
-a sync service for receiving build contexts, two persistent volumes, an NFS volume provisioner for one of those volumes,
-and a couple of small utility services.
+After enabling this mode (we currently still default to the `local-docker` mode), you will need to run `garden plugins kubernetes cluster-init --env=<env-name>` for each applicable environment, in order to install the required cluster-wide services. Those services include the Docker daemon itself, as well as an image registry, a sync service for receiving build contexts, two persistent volumes, an NFS volume provisioner for one of those volumes, and a couple of small utility services.
 
 Make sure your cluster has enough resources and storage to support the required services, and keep in mind that these
 services are shared across all users of the cluster. Please look at the
@@ -80,9 +76,7 @@ details.
 
 ### Kaniko
 
-This mode works _mostly_ the same way as Cluster Docker, but replaces the Docker daemon with
-[Kaniko](https://github.com/GoogleContainerTools/kaniko).
-Enable this by setting `buildMode: kaniko` in your `kubernetes` provider configuration.
+This mode works _mostly_ the same way as Cluster Docker, but replaces the Docker daemon with [Kaniko](https://github.com/GoogleContainerTools/kaniko). Enable this by setting `buildMode: kaniko` in your `kubernetes` provider configuration, and running `garden plugins kubernetes cluster-init --env=<env-name>` to install required cluster-wide service.
 
 The Kaniko project is still improving, but it provides a
 compelling alternative to the standard Docker daemon because it can run without special privileges on the cluster,

docs/reference/commands.md

@@ -113,7 +113,7 @@ Examples:
 Deletes a running environment.
 
 This will delete all services in the specified environment, and trigger providers to clear up any other resources
-and reset it. When you then run `garden init` or `garden deploy`, the environment will be reconfigured.
+and reset it. When you then run `garden deploy`, the environment will be reconfigured.
 
 This can be useful if you find the environment to be in an inconsistent state, or need/want to free up
 resources.
@@ -374,28 +374,6 @@ garden get debug-info --include-project  # include provider info for the project
   | `--include-project` |  | boolean | Include project-specific information from configured providers.
 Note that this may include sensitive data, depending on the provider and your configuration.
 
-### garden init
-
-Initialize system, environment or other runtime components.
-
-This command needs to be run before first deploying a Garden project, and occasionally after updating Garden,
-plugins or project configuration.
-
-Examples:
-
-    garden init
-    garden init --force   # runs the init flows even if status checks report that the environment is ready
-
-##### Usage
-
-    garden init [options]
-
-##### Options
-
-| Argument | Alias | Type | Description |
-| -------- | ----- | ---- | ----------- |
-  | `--force` |  | boolean | Force initalization of environment, ignoring the environment status check.
-
 ### garden link source
 
 Link a remote source to a local directory.

docs/reference/config.md

@@ -160,8 +160,8 @@ environments:
     #
     # Setting this flag to `true` will activate the protection on the `deploy`, `test`, `task`,
     # `build`,
-    # `init` and `dev` commands. A protected command will ask for a user confirmation every time
-    # is run agains
+    # and `dev` commands. A protected command will ask for a user confirmation every time is run
+    # agains
     # an environment marked as production.
     # Run the command with the "--yes" flag to skip the check (e.g. when running Garden in CI).
     #
@@ -493,7 +493,7 @@ The name of the environment.
 Flag the environment as a production environment.
 
 Setting this flag to `true` will activate the protection on the `deploy`, `test`, `task`, `build`,
-`init` and `dev` commands. A protected command will ask for a user confirmation every time is run agains
+and `dev` commands. A protected command will ask for a user confirmation every time is run agains
 an environment marked as production.
 Run the command with the "--yes" flag to skip the check (e.g. when running Garden in CI).
 

examples/istio/README.md

@@ -62,22 +62,14 @@ kubectl create namespace istio-system
 kubectl apply -f istio.yaml
 ```
 
-### Step 4 - Initialize the Garden project
-
-For Istio to work, we need to label the project namespace. Garden creates a namespace for the project when we run the `init` command:
-
-```sh
-garden init
-```
-
-The namespace name is the same as the project name, in this case `istio-example`.
-
-### Step 5 - Label the namespace with `istio-injection=enabled`
+### Step 4 - Prepare your project namespace
 
+For Istio to work, we need to label the project namespace. The namespace name is by default the same as the project name, in this case `istio-example`.
 Once the project namespace has been created, we need to label it with `istio-injection=enabled` for the Istio-sidecar-injector to work:
 
 ```sh
- kubectl label namespace istio-example istio-injection=enabled
+kubectl create namespace istio-example
+kubectl label namespace istio-example istio-injection=enabled
 ```
 
 ## Usage

examples/kubernetes-secrets/README.md

@@ -5,30 +5,21 @@ one of the modules.
 
 ## Setup
 
-The commands below assume you're running a local Kubernetes cluster. Please adjust the commands accordingly if you're
-running against a remote environment (setting the `--env` parameter and the correct `--namespace` for kubectl).
+_Note: The commands below assume you're running a local Kubernetes cluster. Please adjust the commands accordingly if you're running against a remote environment (setting the `--env` parameter and the correct `--namespace` for kubectl)._
 
-### 1. Initialize the project
-
-```sh
-garden init
-```
-
-### 2. Create the Secret
+First create the Secret in your Kubernetes cluster:
 
 ```sh
 kubectl --namespace=kubernetes-secrets create secret generic my-secret --from-literal=my-key=superdupersecret
 ```
 
-## Usage
-
-First deploy the services:
+Then deploy the services:
 
 ```sh
 garden deploy
 ```
 
-Then try calling the frontend service and observe the value you set in the Secret above:
+Finally, try calling the frontend service and observe the value you set in the Secret above:
 
 ```sh
 garden call backend

garden-service/src/commands/commands.ts

@@ -9,7 +9,6 @@
 import { Command } from "./base"
 import { BuildCommand } from "./build"
 import { CallCommand } from "./call"
-import { InitCommand } from "./init"
 import { DeleteCommand } from "./delete"
 import { DeployCommand } from "./deploy"
 import { DevCommand } from "./dev"
@@ -38,7 +37,6 @@ export const coreCommands: Command[] = [
   new DevCommand(),
   new ExecCommand(),
   new GetCommand(),
-  new InitCommand(),
   new LinkCommand(),
   new LogsCommand(),
   new OptionsCommand(),

garden-service/src/commands/delete.ts

@@ -84,7 +84,7 @@ export class DeleteEnvironmentCommand extends Command {
 
   description = dedent`
     This will delete all services in the specified environment, and trigger providers to clear up any other resources
-    and reset it. When you then run \`garden init\` or \`garden deploy\`, the environment will be reconfigured.
+    and reset it. When you then run \`garden deploy\`, the environment will be reconfigured.
 
     This can be useful if you find the environment to be in an inconsistent state, or need/want to free up
     resources.

garden-service/src/config/project.ts

@@ -84,7 +84,7 @@ export const environmentSchema = environmentConfigSchema.keys({
       Flag the environment as a production environment.
 
       Setting this flag to \`true\` will activate the protection on the \`deploy\`, \`test\`, \`task\`, \`build\`,
-      \`init\` and \`dev\` commands. A protected command will ask for a user confirmation every time is run agains
+      and \`dev\` commands. A protected command will ask for a user confirmation every time is run agains
       an environment marked as production.
       Run the command with the "--yes" flag to skip the check (e.g. when running Garden in CI).
 

garden-service/test/e2e/src/pre-release.ts

@@ -46,21 +46,12 @@ describe("PreReleaseTests", () => {
     return new GardenWatch(dir, command)
   }
 
-  async function initIfRemote() {
-    // Assume env is remote if passed as arg
-    if (env) {
-      mlog.log("initing project", project)
-      await runWithEnv(["init"])
-    }
-  }
-
   const namespaces = getProjectNamespaces()
   const projectPath = resolve(examplesDir, project)
 
   before(async () => {
     mlog.log("deleting .garden folder")
     await removeExampleDotGardenDir(projectPath)
-    await initIfRemote()
   })
 
   after(async () => {