Review the Need for the Dynamic-Client

[otaviof]

During the bootstrap of this project we thought the dynamic-client would be useful at some point, so this CLI project would not have to import all Kubernetes typed clients. However, in practice we do import Shipwright types (in go.mod), and we only rely on core/v1, so in other words, all types we need are already present.

Later on #19, we notice a change in the test behavior, which implies more effort on testing and making sure the results are adequate.

With that said, should we retire the dynamic-client, make sure we refactor this in an early project phase?

[imjasonh]

+1 to using typed clients, since we know ahead of time what types we expect to use. I'm not sure the flexibility of the dynamic client is buying us anything, and it's introducing weird test behavior, so let's drop it.

[imjasonh]

cc @alicerum @adambkaplan

[alicerum]

+1 from me for the typed clients. Dynamic ones are awesome for apps like kubectl that need to work with unknown types. For us it's close to 0 benefits.

[adambkaplan]

Likewise a +1 to using the typed client, which we generate in shipwright-io/build and we already pull in as a dependency.

Note that if we find ourselves having harder dependencies on Tekton, we may need to pull in the pipeline client as a dependency. This isn't the case today, and may never be an issue (by way of example - the PRs for fetching logs bypass Tekton and go straight to the underlying pod).

[gabemontero]

@otaviof unless you had a branch you are close to publishing for this, I'll take this on with my next "Gabe's set of available cycles for shipwright" work.

Probably can start next week.