Skaffold: `skaffold dev` issues/suggestion

Created on 18 Mar 2018  路  6Comments  路  Source: GoogleContainerTools/skaffold

Hey folks,

First want to say skaffold is looking great for a first release.

Second, skaffold dev is a bit too much of an overkill. What I mean by that is, a whole image build->deployment->actual application bootstrap (including bringing any external dependencies) every save doesn't seem to be optimal if the only change happened to the code (say a comment).

Ideally what should happen is:

  • Save (delta in file detected)
  • Notice nothing else other than code changed
  • Only copy the code to the containers already deployed

I'm not sure there's a good solution to this problem, but would be immensely helpful and useful to have code-only updates.

skaffold version: 0.2.0
OS: OSX
K8s environ: minikube
K8s version: 1.9.x

kinfeature-request

Most helpful comment

Yes, we currently detect the file deltas and use that to trigger the dev cycle. Theres a few places where we could immediately improve using this metadata. A few off the top of my head.

  1. incremental context building - this is simpler with systems like GCB that look to cloud storage for the context, but there is also an experimental flag to the docker daemon for context streaming.
  2. some more magic preprocessing to skip steps
  3. debug/exec story. Clearly for interpreted languages, we could have some considerable speed up by not repackaging and redeploying the entire image. We should investigate how we could support those workflows in the most generic way.

All 6 comments

I agree with the overkill description, it would be better to support volumes to mount the code and then just have a field of which command to trigger on any code change.

This is important because your third point will not work in a compiled language (e.g go, rust). It will work pretty well on interpreted/frontend.

Yes, we currently detect the file deltas and use that to trigger the dev cycle. Theres a few places where we could immediately improve using this metadata. A few off the top of my head.

  1. incremental context building - this is simpler with systems like GCB that look to cloud storage for the context, but there is also an experimental flag to the docker daemon for context streaming.
  2. some more magic preprocessing to skip steps
  3. debug/exec story. Clearly for interpreted languages, we could have some considerable speed up by not repackaging and redeploying the entire image. We should investigate how we could support those workflows in the most generic way.

Yeah, a few possible ideas on the "magic" aspect.

If there is a change in a file that has no "run" commands (or onbuild run) after it, it should be safe to skip the rebuild and do a sync/restart in place.

If we had a way to tell what files are looked at during a run command (ptrace?), we could potentially skip even more rebuilds.

We use skaffold for java projects. The Dockerfile copies the bootable jar into the image. Therefor deploying on code changes does not have any effect (it deploys the same old jar over again). It would be nice to just watch the output dir for new jar files. So being able to specify a watchpath would be nice.

This looks promising https://github.com/vapor-ware/ksync

cc @pquerna

Closing this, as this issue is covered by the following issues:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Morriz picture Morriz  路  3Comments

r2d4 picture r2d4  路  3Comments

kdevu picture kdevu  路  3Comments

gbird3 picture gbird3  路  3Comments

Hudsonzp picture Hudsonzp  路  4Comments