Specs and watches should have the option to be locally defined

[wojtek-viirtue]

TLDR;
Having the ability to define specs within a working directory would be a great way to limit what a ksync watch is watching.

Our CD pipelines build and push images to a container registry. In addition to using helm for deployments via Argo CD, developers rely on helm to locally update their minikube cluster to make sure they have all the moving parts of our application. Enter a potential issue with ksync.

Currently all specs are defined globally. Starting a watch watches all the specs defined. This is a great feature however, there are some potential pitfalls when multiple watches are defined.

If a developer used helm to deploy the latest and greatest, had a watch defined for one or more repos and forgot to pull from all the repos defined....they no longer have the latest and greatest. Ksync will have overwritten the latest with the stale code.

---

Possible Solve

I think it would be great to introduce a local context for spec. For instance

ksync create --selector=app=whatever --namespace whatever $(pwd) /app -c whatever-container --local-read-only .

would create the spec in the current directory because of the "." as the very end of the command.

When a watch was triggered it would see if there was a locally defined spec in the current working directory, if there was...it'd use it. Otherwise, it'd default to the globally defined ones. This way a developer can opt into what's being watched.

To come full circle, it doesn't solve the issue of if a developer forgot to pull from git, but now they only have to worry about pulling from one repo vs N repos.

It should also be noted that the inability to make changes to a spec without a ksync watch running, kicks off potentially unwanted syncs and you're forced to edit the specs manually in the ksync.yaml beforehand.

[grampelberg]

I'm not sure I quite understand the problem. Developers update their images but don't update git, so the sync overwrites potentially newer code?

[wojtek-viirtue]

I'm not sure I quite understand the problem. Developers update their images but don't update git, so the sync overwrites potentially newer code?

@grampelberg
That's exactly right. Plus the fact that you may not want to always watch everything all the time.

[grampelberg]

It sounds like maybe instead of having a daemon doing all the syncing in the background a better solution would be to just have a command that the devs run in each directory they want sync'd then?

[wojtek-viirtue]

@grampelberg I think that would be an excellent solve!

[timfallmk]

It sounds like the original suggestion might still be helpful in other situations. I wonder how much work it would take to do.