Add API build trigger

[nkubala]

This adds an API build trigger type, which allows users to use the gRPC/HTTP server in skaffold to trigger builds in place of the polling/manual triggers.

When using the API trigger in dev mode, skaffold will only rebuild images if a trigger is issued by the user (and if files have changed since the last rebuild).

[codecov-io]

Codecov Report

Merging #2201 into master will decrease coverage by 0.41%.
The diff coverage is 24.39%.

@@            Coverage Diff             @@
##           master    #2201      +/-   ##
==========================================
- Coverage   58.56%   58.14%   -0.42%     
==========================================
  Files         188      188              
  Lines        7792     7863      +71     
==========================================
+ Hits         4563     4572       +9     
- Misses       2858     2919      +61     
- Partials      371      372       +1

Impacted Files	Coverage Δ
pkg/skaffold/event/event.go	89.65% <ø> (ø)	⬆️
pkg/skaffold/server/proto/skaffold.pb.gw.go	7.35% <0%> (ø)
pkg/skaffold/server/endpoints.go	0% <0%> (ø)	⬆️
pkg/skaffold/server/proto/skaffold.pb.go	5.66% <0%> (ø)
pkg/skaffold/runner/context/context.go	62.5% <100%> (+1.2%)	⬆️
pkg/skaffold/server/server.go	54.68% <100%> (+3.02%)	⬆️
pkg/skaffold/runner/runner.go	69.1% <100%> (ø)	⬆️
pkg/skaffold/watch/triggers.go	45.65% <37.5%> (-6.41%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 81a56b1...b429454. Read the comment docs.

[tejal29]

This adds an API build trigger type, which allows users to use the gRPC/HTTP server in skaffold to trigger builds in place of the polling/manual triggers.

Can you give an example how this works?
e.g.: will there be a skaffold service started locally and then watch for triggers?
How do you start the gRPC/HTTP server?

Or is this part of skaffold dev flow only because that is when gRPC and HTTP servers are started?

[nkubala]

Or is this part of skaffold dev flow only because that is when gRPC and HTTP servers are started?

exactly, sorry I wasn't very descriptive here. the default trigger is polling which means "the watcher will poll for file changes every X milliseconds, and rebuild if it finds any". this adds a new api trigger type which means "the watcher will poll for file changes only when the user tells it to". so in practice it would look like

$ skaffold dev --trigger api

...
make some file changes...

$ curl http://localhost:<skaffold_http_port>/v1/build

users can also use a gRPC client instead of curl and achieve the same result.

conn, err := grpc.Dial(skaffoldRPCAddr, grpc.WithInsecure())
if err != nil {
	fmt.Printf("error opening connection: %s\n", err.Error())
	os.Exit(1)
}
defer conn.Close()
client := proto.NewSkaffoldServiceClient(conn)
_, err := client.Build(ctx, &empty.Empty{})
if err != nil {
	fmt.Printf("error issuing build request: %v\n", err)
}

[tejal29]

Overall this looks good. Just few clarifications.

[tejal29]

This looks great!
I was thinking the Control API is per stage and i was wondering if there are future plans to specify it per stage i.e. "build", "test" and "deploy".
An example use-case would be:
I am k8 developer developing running skaffold dev. I make some changes to my build code and now my container structure test fail as expected.
I change my tests (e.g. config file for container structure test). In this case, it would be sufficient to trigger just the tests and no deploy.
(i am aware build will probably be a no-op since no build files were changed)

Another example:
I changed on the manifest which is deploying a 3rd party container image. In that case, i want to trigger just deploy.

Not to be tackled in this PR, but would be great to know if we plan to do this future.

[tejal29]

LGTM except a nit on apiServer.Interval

[nkubala]

@tejal29 spot on, I'll be sending a follow up PR that adds a trigger for deploys as well. the idea is to split the dev loop into its individual components and give users the ability to control each one independently (if they want to).

I haven't figured out the story for testing yet though: I originally considered it to be part of the build step, but your example makes a good point. I suppose users could specify their test files as build dependencies for the artifact they're testing, but I'll think more about it.

addressed comments

[balopat]

looking good, I have only one concern left

[balopat]

LGTM