github.com/GoogleContainerTools/skaffold/v2@v2.13.2/docs-v2/content/en/docs/workflows/dev.md (about)

     1  ---
     2  title: "skaffold dev"
     3  linkTitle: "Continuous Development"
     4  featureId: dev
     5  weight: 20
     6  ---
     7  
     8  `skaffold dev` enables continuous local development on an application.
     9  While in `dev` mode, Skaffold will watch an application's source files, and when it detects changes,
    10  will rebuild your images (or sync files to your running containers), push any new images, test built images, and redeploy the application to your cluster.
    11  
    12  `skaffold dev` is considered Skaffold's main mode of operation, as it allows you
    13  to leverage all of the features of Skaffold in a continuous way while iterating
    14  on your application.
    15  
    16  {{<alert title="💡 Tip">}}
    17  Running `skaffold dev` is equivalent to running the IDE command `Run on Kubernetes` if you're using Skaffold with the [Cloud Code IDE extensions]({{< relref "../install/#managed-ide" >}}). In addition to this guide you should also look at the corresponding guides for [VSCode](https://cloud.google.com/code/docs/vscode/running-an-application), [IntelliJ](https://cloud.google.com/code/docs/intellij/deploying-a-k8-app) and [Cloud Shell](https://ide.cloud.google.com/?walkthrough_tutorial_url=https%3A%2F%2Fwalkthroughs.googleusercontent.com%2Fcontent%2Fgke_cloud_code_create_app%2Fgke_cloud_code_create_app.md).
    18  {{</alert>}}
    19  
    20  ## Dev loop
    21  
    22  When `skaffold dev` is run, Skaffold will first do a full build, test, render and deploy of all artifacts specified in the `skaffold.yaml`, similar to `skaffold run`. By default, Skaffold will exit if any of these stages fails.  Upon successful build, test, render 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 and retest the associated artifacts, and redeploy the new changes to your cluster.
    23  
    24  The ``--keep-running-on-failure`` flag can be used to keep Skaffold running by suspending the Skaffold session while encountering errors in the first build, test, render, deploy. The user can attempt to fix the errors and then restore the session by pressing any key or exit the session with ``Ctrl+C``. The session will be suspended again unless the errors are fixed.  Using this flag should result in an better experience for `dev` sessions where errors occur that would otherwise cause Skaffold to exit
    25  
    26  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.
    27  
    28  ## Precedence of Actions
    29  
    30  The actions performed by Skaffold during the dev loop have precedence over one another, so that behavior is always predictable. The order of actions is:
    31  
    32  1. [File Sync]({{<relref "/docs/filesync" >}})
    33  1. [Build]({{<relref "/docs/builders" >}})
    34  1. [Test]({{<relref "/docs/testers" >}})
    35  1. [Deploy]({{<relref "/docs/deployers" >}})
    36  
    37  ## File Watcher and Watch Modes
    38  
    39  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.
    40  
    41  By default, Skaffold uses filesystem notifications of your OS to monitor changes
    42  on the local filesystem and re-runs the loop on every change.
    43  
    44  Skaffold also supports a `polling` mode where the filesystem is checked for
    45  changes on a configurable interval, or a `manual` mode, where Skaffold waits for
    46  user input to check for file changes. These watch modes can be configured
    47  through the `--trigger` flag.
    48  
    49  ## Controlling the Dev Loop with API
    50  
    51  {{< alert title="Note">}}
    52  This section is intended for developers who build tooling on top of Skaffold.
    53  {{</alert>}}
    54  
    55  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 Skaffold API.
    56  
    57  With this API, users can selectively turn off the automatic dev loop and can tell Skaffold to wait for user input before performing any of these actions, even if the requisite files were changed on the filesystem. By doing so, users can "queue up" changes while they are iterating locally, and then have Skaffold rebuild and redeploy only when asked. This can be very useful when builds are happening more frequently than desired, when builds or deploys take a long time or are otherwise very costly, or when users want to integrate other tools with `skaffold dev`.
    58  
    59  For more documentation, see the [Skaffold API Docs]({{<relref "/docs/design/api" >}}).