Add docs for dev and ci/cd workflows#3153
Add docs for dev and ci/cd workflows#3153nkubala merged 6 commits intoGoogleContainerTools:masterfrom
Conversation
|
Error creating deployment docs-controller-deployment-3153, please visit https://storage.googleapis.com/webhook-logs/logs-3153-1572648605517032097 to view logs. |
|
Error creating deployment docs-controller-deployment-3153, please visit https://storage.googleapis.com/webhook-logs/logs-3153-1572649397939723994 to view logs. |
|
Error creating deployment docs-controller-deployment-3153, please visit https://storage.googleapis.com/webhook-logs/logs-3153-1572651452840099581 to view logs. |
|
Error creating deployment docs-controller-deployment-3153, please visit https://storage.googleapis.com/webhook-logs/logs-3153-1572651987827066368 to view logs. |
|
|
||
| ## 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. |
There was a problem hiding this comment.
I dont think we have skaffold run documented any where. we can drop it or link to existing CLI doc on run.
| 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 |
There was a problem hiding this comment.
I think we should explain trigger types here and not control api.
There was a problem hiding this comment.
also, I'm writing a section about the Control API :)
There was a problem hiding this comment.
I just wanted to have a little section about it here for discoverability, and then link in the full docs to the control API. I mentioned the trigger types above this section. do you think I should remove this?
There was a problem hiding this comment.
I'd make it smaller and refer to Skaffold API as an advanced topic for those who want to integrate tools with skaffold dev or have finer grained control and point them to the /docs/design/api docs - it is not essential for the CLI users. WDYT?
There was a problem hiding this comment.
I agree, control API is not for CLI user and more of integration for tools.
There was a problem hiding this comment.
sounds reasonable, I do think CLI users could still potentially make use of the control API, but it's not a first class feature. I cut down the blurb to just explain what it is and why you might use it, and then pointed to the API docs
|
Please visit http://35.235.117.222:1313 to view changes to the docs. |
|
Please visit http://35.236.87.39:1313 to view changes to the docs. |
|
Please visit http://34.94.185.45:1313 to view changes to the docs. |
Co-Authored-By: Balint Pato <balopat@users.noreply.github.com>
|
|
Fixes #3074