Skip to content

Add --auto-trigger option to kev dev with Skaffold#352

Merged
marcinc merged 2 commits intomasterfrom
kev-dev-trigger-option
Dec 8, 2020
Merged

Add --auto-trigger option to kev dev with Skaffold#352
marcinc merged 2 commits intomasterfrom
kev-dev-trigger-option

Conversation

@marcinc
Copy link
Member

@marcinc marcinc commented Dec 3, 2020

Addresses #344

This PR adds additional command line flag specific to kev dev with --skaffold flow enabled.

By default kev dev will build/push/deploy first time and then wait for user input (in a form of ENTER button) to trigger another build/push/deploy iteration. It's the default to prevent unnecessary avalanche of rebuilds and deploys happening on each source code change.

In order to enable automatic build/push/deploy on each project source code change user must specify --auto-trigger flag.

@marcinc marcinc requested a review from ezodude December 3, 2020 15:15
@marcinc marcinc linked an issue Dec 3, 2020 that may be closed by this pull request
ezodude
ezodude previously approved these changes Dec 3, 2020
Copy link
Contributor

@ezodude ezodude left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks fine and makes sense 👍

But, here are my 2 pennies ...

Is there a better way of surfacing --auto-trigger - even make it the default behaviour?

Looking at all the new extra flags, it feels like they complicate how the --skaffold option can be used.

Running kev dev --help presents the below ... which is quite a lot to grok and use.

$ kev dev --help
(dev) Continuous reconcile and re-render of K8s manifests with optional project build, push and deploy (using --skaffold).

Examples:

   ### Run Kev in dev mode
   $ kev dev

   ### Use a custom directory to render manifests
   $ kev dev -d my-manifests

   ### Activate the Skaffold dev loop to build, push and deploy your project
   $ kev dev --skaffold

   ### Activate the Skaffold dev loop to build, push and deploy your project to a particular namespace
   $ kev dev --skaffold --namespace myspace

   ### Activate the Skaffold dev loop to build, push and deploy your project using a specific kubecontext
   $ kev dev --skaffold --namespace myspace --kubecontext mycontext

   ### Activate the Skaffold dev loop to build, push and deploy your project and tail deployed app logs
   $ kev dev --skaffold --tail

   ### Activate the Skaffold dev loop to build, push and deploy your project "staging" configuration
   $ kev dev --skaffold --kev-env staging

   ### Activate the Skaffold dev loop to build, push and deploy your project automatically on every code change
   $ kev dev --skaffold --auto-trigger

Usage:
  kev dev [flags]

Flags:
  -f, --format string        Deployment files format. Default: Kubernetes manifests. (default "kubernetes")
  -s, --single               Controls whether to produce individual manifests or a single file output. Default: false
  -d, --dir string           Override default Kubernetes manifests output directory. Default: k8s/<env>
      --skaffold             [Experimental] Activates Skaffold dev loop.
  -n, --namespace string     [Experimental] Kubernetes namespaces to which Skaffold dev deploys the application. (default "default")
  -k, --kubecontext string   [Experimental] Kubernetes context to be used by Skaffold dev.
      --kev-env string       [Experimental] Kev environment that will be deployed by Skaffold. If not specified it'll use the sandbox dev env. (default "dev")
  -t, --tail                 [Experimental] Enable Skaffold deployed application log tailing.
  -a, --auto-trigger         [Experimental] Enable Skaffold to automatically trigger build/push/deploy on each application source code change. Defaults to 'manual' trigger.
  -h, --help                 help for dev

@marcinc
Copy link
Member Author

marcinc commented Dec 4, 2020

@ezodude these are just a few different use examples. As for making --auto-trigger a the default behaviour I guess we could do that. The reasoning behind making that manual by default was to slow down the build/push/deploy loop and give user a chance to batch changes before releasing them to the cluster. But thinking about it now, perhaps it should be the opposite as you suggested above.

…ill allow users to manually trigger build/push/deploy after series of source code changes.
Copy link
Contributor

@ezodude ezodude left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@marcinc marcinc merged commit c15ac93 into master Dec 8, 2020
@marcinc marcinc deleted the kev-dev-trigger-option branch December 8, 2020 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add --trigger flag to kev dev

2 participants