nits

Author: balopat

docs/content/en/docs/workflows/ci-cd.md

@@ -6,25 +6,40 @@ weight: 3
 
 Skaffold offers several sub-commands for its workflows that make it quite flexible when integrating with CI/CD pipelines.
 
-## `skaffold build` | `skaffold deploy`
+## `skaffold build | skaffold deploy`
 
 `skaffold build` will build your project's artifacts, and push the build images to the specified registry. If your project is already configured to run with Skaffold, `skaffold build` can be a very lightweight way of setting up builds for your CI pipeline. Passing the `--file-output` flag to Skaffold build will also write out your built artifacts in JSON format to a file on disk, which can then by passed to `skaffold deploy` later on. This is a great way of "committing" your artifacts when they have reached a state that you're comfortable with, especially for projects with multiple artifacts for multiple services.
 
 Example using the current git state as a unique file ID to "commit" build state:
 
-```code
-➜  getting-started git:(docs) ✗ export STATE=$(git rev-list -1 HEAD --abbrev-commit)
-
-➜  getting-started skaffold build --file-output build-$STATE.json
+Storing the build result in a commit specific JSON file:
+```bash
+export STATE=$(git rev-list -1 HEAD --abbrev-commit)
+skaffold build --file-output build-$STATE.json
+```
+outputs:
+```bash 
 Generating tags...
  - gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db
 Checking cache...
  - gcr.io/k8s-skaffold/skaffold-example: Found. Tagging
+```
 
-➜  getting-started cat build-$STATE.json
+The content of the JSON file
+```bash 
+cat build-$STATE.json
+```
+outputs: 
+```json
 {"builds":[{"imageName":"gcr.io/k8s-skaffold/skaffold-example","tag":"gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db@sha256:eeffb639f53368c4039b02a4d337bde44e3acc728b309a84353d4857ee95c369"}]}
+```
 
-➜  getting-started git:(docs) ✗ skaffold deploy -a build-$STATE.json
+We can use this build result file to deploy:
+```bash
+skaffold deploy -a build-$STATE.json
+```
+Outputs:
+```bash
 Tags used in deployment:
  - gcr.io/k8s-skaffold/skaffold-example -> gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db@sha256:eeffb639f53368c4039b02a4d337bde44e3acc728b309a84353d4857ee95c369
 Starting deploy...
@@ -37,9 +52,8 @@ Skaffold also has another built-in command, `skaffold render`, that will perform
 
 Example of running `skaffold render` to render Kubernetes manifests, then sending them directly to `kubectl`:
 
-```code
-➜  getting-started skaffold render --output render.txt
-➜  getting-started cat render.txt
+Running `skaffold render --output render.txt && cat render.txt` outputs:
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -49,14 +63,16 @@ spec:
   containers:
   - image: gcr.io/k8s-skaffold/skaffold-example:v0.41.0-57-gbee90013@sha256:eeffb639f53368c4039b02a4d337bde44e3acc728b309a84353d4857ee95c369
     name: getting-started
+```
 
-➜  getting-started cat render.txt | kubectl apply -f -
+We can then pipe this yaml to kubectl ` cat render.txt | kubectl apply -f -`:  
+```
 pod/getting-started configured
 ```
 
 Or, skipping the file writing altogether:
 
 ```code
-➜  getting-started skaffold render | kubectl apply -f -
+skaffold render | kubectl apply -f -
 pod/getting-started configured
 ```

docs/content/en/docs/workflows/dev.md

@@ -4,40 +4,34 @@ linkTitle: "Continuous development"
 weight: 1
 ---
 
-## `skaffold dev`
-
 `skaffold dev` enables continuous local development on an application.
 While in `dev` mode, Skaffold will watch an application's source files, and when it detects changes,
 will rebuild your images (or sync files to your running containers), push any new images, and redeploy the application to your cluster.
 
 `skaffold dev` is considered Skaffold's main mode of operation, as it allows you
-to leverage all of the main features of Skaffold in a continuous way while iterating
+to leverage all of the features of Skaffold in a continuous way while iterating
 on your application.
 
-
 ## Dev loop
 
-When `skaffold dev` is run, Skaffold will first do a full build and deploy of all artifacts specified in the `skaffold.yaml`, identical behavior to `skaffold run`. Upon successful build and deploy, Skaffold will start watching all source file dependencies for all artifacts specified in the project. As changes are made to these source files, Skaffold will rebuild the associated artifacts, and redeploy the new changes to your cluster.
-
-The dev loop will run until the user cancels the Skaffold process with `Ctrl+C`. Upon receiving this signal, Skaffold will clean up all deployed artifacts on the active cluster, meaning that Skaffold won't abandon any Kubernetes resources that it created throughout the lifecycle of the run.
+When `skaffold dev` is run, Skaffold will first do a full build and deploy of all artifacts specified in the `skaffold.yaml`, similar to `skaffold run`. Upon successful build and deploy, Skaffold will start watching all source file dependencies for all artifacts specified in the project. As changes are made to these source files, Skaffold will rebuild the associated artifacts, and redeploy the new changes to your cluster.
 
+The dev loop will run until the user cancels the Skaffold process with `Ctrl+C`. Upon receiving this signal, Skaffold will clean up all deployed artifacts on the active cluster, meaning that Skaffold won't abandon any Kubernetes resources that it created throughout the lifecycle of the run. This can be optionally disabled by using the `--no-prune` flag.
 
 ## Precedence of Actions
 
 The actions performed by Skaffold during the dev loop have precendence over one another, so that behavior is always predictable. The order of actions is:
 
-1) File Sync
-1) Build
-1) Deploy
-
+1. File Sync
+1. Build
+1. Deploy
 
 ## File Watcher and Watch Modes
 
 Skaffold computes the dependencies for each artifact based on the builder being used, and the root directory of the artifact. Once all source file dependencies are computed, in `dev` mode, Skaffold will continuously watch these files for changes in the background, and conditionally re-run the loop when changes are detected.
 
 By default, Skaffold uses `fsnotify` to monitor events on the local filesystem. Skaffold also supports a `polling` mode where the filesystem is checked for changes on a configurable interval, or a `manual` mode, where Skaffold waits for user input to check for file changes. These watch modes can be configured through the `--trigger` flag.
 
-
 ## Control API
 
 By default, the dev loop will carry out all actions (as needed) each time a file is changed locally, with the exception of operating in `manual` trigger mode. However, individual actions can be gated off by user input through the Control API.

go.mod

@@ -46,7 +46,6 @@ require (
 	github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
 	github.com/golang/groupcache v0.0.0-20191002201903-404acd9df4cc // indirect
 	github.com/golang/protobuf v1.3.2
-	github.com/google/btree v1.0.0 // indirect
 	github.com/google/go-cmp v0.3.1
 	github.com/google/go-containerregistry v0.0.0-20191017210159-68bc585818ee
 	github.com/google/go-github v17.0.0+incompatible