Add control API to pause and resume autoBuild, autoDeploy and autoSync

[gsquared94]

Fixes: #2806
Description

Add control API to pause and resume autoBuild, autoDeploy and autoSync
User facing changes (remove if N/A)

API Contract

[codecov]

Codecov Report

Merging #4145 into master will decrease coverage by 0.43%.
The diff coverage is 43.05%.

Impacted Files	Coverage Δ
pkg/skaffold/server/endpoints.go	0.00% <0.00%> (ø)
pkg/skaffold/server/server.go	53.65% <25.00%> (-4.92%)	⬇️
pkg/skaffold/runner/new.go	64.51% <42.85%> (-3.82%)	⬇️
pkg/skaffold/runner/intent.go	79.31% <70.00%> (-20.69%)	⬇️
pkg/skaffold/event/event.go	90.52% <71.42%> (-2.01%)	⬇️

[nkubala]

I tried this out locally, and I'm seeing strange behavior with the microservices example. when I set auto-deploy to false with curl -X POST http://localhost:50052/v1/auto_execute -d '{"deploy": false}', changes aren't triggering a rebuild when they should be. at first glance I don't see any copy paste errors, but can you try this example out and see if you're seeing the same issue?

also, it would be great if we could expose the state of each "switch" in the exposed state object. sometimes I lose track of where I am, and it would be nice to have a way to tell. this would also be useful for the IDEs to integrate this so they wouldn't have to keep track in the client (though they may anyway). this could come in a follow up PR though

[gsquared94]

I tried this out locally, and I'm seeing strange behavior with the microservices example. when I set auto-deploy to false with curl -X POST http://localhost:50052/v1/auto_execute -d '{"deploy": false}', changes aren't triggering a rebuild when they should be. at first glance I don't see any copy paste errors, but can you try this example out and see if you're seeing the same issue?

I think that's because {"deploy": false} is equivalent to {"build": false, "sync": false, "deploy": false} since the missing parameters in rpc request is set to default value AFAIK. That's something I wanted your opinion on. Either we use struct params (instead of boolean) in Intent otherwise we'll need 3 API's for the three phases separately. Which do you think is better?

[gsquared94]

also, it would be great if we could expose the state of each "switch" in the exposed state object. sometimes I lose track of where I am, and it would be nice to have a way to tell. this would also be useful for the IDEs to integrate this so they wouldn't have to keep track in the client (though they may anyway). this could come in a follow up PR though

It should be there as AutoTrigger property in BuildState, DeployState and FileSyncState already. The API doesn't return params if they are their default value. So if you ran with auto-build=false then the state api response won't show AutoTrigger param for BuildState.

Review comments addressed

[nkubala]

this is looking great! just tried it out locally and it works exactly how i'd expect. my only comment is i think it would be nice if the server was able to tell me when i'm providing a malformed response or an unsupported HTTP method - I was trying POST for a while, and malformed payloads as well, and the server just responds with {}. it would also be nice if the server could tell me if i'm trying to flip the trigger to a position it's already in, e.g. if we've already turned off auto-build, and we try to again, the server could send a quick message saying "auto building is already disabled" or something.

these are just improvements though, and could come in follow up PRs.