Add transport implementation for agent

[chrisdoherty4]

Builds on #730.

The new agent requires a transport to retrieve workflows. The initial transport to be implemented is gRPC as its worked well for the tink-worker (the agents predecessor).

The transport is responsible for connecting to the Tink Server, identifying the node by submitting the nodes unique identifier and subsequently passing along workflows. Unlike the Tink Worker implementation, this transport provides a mechanism for publishing workflow events. The events are what provides insight into the progression of the workflow and are ultimately used by the Tink Server to update the workflow object in Kubernetes.

[codecov]

Codecov Report

Merging #734 (6a593c7) into main (29052da) will decrease coverage by 4.41%.
The diff coverage is 38.49%.

❗ Current head 6a593c7 differs from pull request most recent head d857726. Consider uploading reports for the commit d857726 to get more accurate results

@@            Coverage Diff             @@
##             main     #734      +/-   ##
==========================================
- Coverage   56.31%   51.90%   -4.41%     
==========================================
  Files          28       32       +4     
  Lines        1243     1441     +198     
==========================================
+ Hits          700      748      +48     
- Misses        511      650     +139     
- Partials       32       43      +11     

Impacted Files	Coverage Δ
internal/agent/mock.go	24.44% <0.00%> (ø)
internal/agent/transport/fake.go	0.00% <0.00%> (ø)
internal/agent/transport/grpc.go	23.85% <23.85%> (ø)
internal/agent/agent.go	62.96% <47.22%> (-29.04%)	⬇️
internal/agent/transport/mock.go	52.38% <52.38%> (ø)
internal/agent/run.go	83.67% <73.33%> (-16.33%)	⬇️

... and 2 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[jacobweinstock]

thought this was interesting. Its from the Buf website. https://buf.build/docs/best-practices/style-guide#recommendations

"While controversial, our recommendation is to avoid streaming RPCs. While they certainly have specific use cases that make them extremely valuable, on the whole they generally cause a lot of problems, push RPC framework logic up the stack, and usually prevent developing more reliable architectures."

[jacobweinstock]

Also, would you me open to a name change here? maybe StreamWorkflows -> GetWorkflows

[chrisdoherty4]

thought this was interesting. Its from the Buf website. buf.build/docs/best-practices/style-guide#recommendations

I'm familiar with this but chose to ignore it because the alternatives I thought about have tradeoffs I wanted to avoid right now. The options I came up with include: (1) polling from the agent to the server for workflows; (2) launching a server in the agent and have the tink-server (now a confusing name) issue unary calls to run workflows.

I wasn't fond of polling even with HTTP2s sticky connections and I wanted to, initially at least, avoid the complexity of launching a server and dealing with the agent going offline etc.

I very open to adopting a different approach and welcome more ideas. Long term I'm interested in migrating to the agent containing a server even though its more complex.

Also, would you me open to a name change here? maybe StreamWorkflows -> GetWorkflows

Yes, no problem.

[jacobweinstock]

one loosely held suggestion for a name change. other than that all good. Thanks for all the work on this!

[chrisdoherty4]

@Mergifyio queue

[mergify]

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at 9a45f7b