After I started working on the implementation, it became evident that the regular CI flow is way too slow for iterating while in-development.
Introduce a quicker way for iterating on vector when working on k8s.
This includes:
- building vector in development mode, with minimal overhead, compared to the regular
cargo build (essentially just use cargo build); ok is works only on the hosts with targets native to k8s (linux, windows);
- building a lightweight container from the said build artifact the quickest way possible (just copy it into the image);
- deploy the build image to the k8s (with the same k8s manifests we use for testing and production).
Possibly use tools like draft or skaffold, but not necessarily - a custom harness would work too, and might be a better fit (especially since we don't yet have Helm chart).
This is just to improve the local iteration speed for development. CI should still go through the longer yet more assuring release-like process. The make test-integration-kubernetes command should also use the long flow.
Work as part of #2222 implementation.
This should be useful for any kind of development that requires k8s, not just for work on the integration and #2222. For instance, if there's a bug that's only reproducible in k8s, but not related directly to #2222 or k8s source.
After I started working on the implementation, it became evident that the regular CI flow is way too slow for iterating while in-development.
Introduce a quicker way for iterating on vector when working on k8s.
This includes:
cargo build(essentially just usecargo build); ok is works only on the hosts with targets native to k8s (linux, windows);Possibly use tools like draft or skaffold, but not necessarily - a custom harness would work too, and might be a better fit (especially since we don't yet have Helm chart).
This is just to improve the local iteration speed for development. CI should still go through the longer yet more assuring release-like process. The
make test-integration-kubernetescommand should also use the long flow.Work as part of #2222 implementation.
This should be useful for any kind of development that requires k8s, not just for work on the integration and #2222. For instance, if there's a bug that's only reproducible in k8s, but not related directly to #2222 or k8s source.