Restore Kubernetes Integration tests #25624
Conversation
tigrato
force-pushed
the
tigrato/enable-kind
branch
19 times, most recently
from
f0eeb9d to
2fbbbe8
Compare
tigrato
force-pushed
the
tigrato/enable-kind
branch
from
2fbbbe8 to
7be72ff
Compare
tigrato
force-pushed
the
tigrato/enable-kind
branch
8 times, most recently
from
a742c41 to
ceb7b04
Compare
| INTEGRATION_KUBE_REGEX := ^.*Kube.* | ||
| .PHONY: integration-root | ||
| integration-kube: FLAGS ?= -v -race | ||
| integration-kube: PACKAGES = $(shell go list ./... | grep 'integration\([^s]\|$$\)') |
There was a problem hiding this comment.
Could you use grep -w integration - that ends up picking the same set of package as the more complicated regex. But I'm not sure if this is future-proofing against some other package names. I notice there is an integrationv1 package that gets selected since it is within an integration package that might otherwise have been missed with grep -w.
...
Ah, I see it was copied from the integration-root target and a variation of the integration target. I wonder what the logic should be. Perhaps we should just be doing go list ./integration/... - lib/auth/integration seems to be the integration service and nothing to do with integration tests, and integrations/lib/testing/integration seems to be an integration test that make integration skips deliberately.
Any idea exactly which tests should be run here?
There was a problem hiding this comment.
The thought occurred to me just now that we should probably be using build tags to determine which tests to run rather than grep. Perhaps there is a reason we do not do that already, so maybe we just stick to the current way.
There was a problem hiding this comment.
I think the issue about using build tags is that it requires special configuration on the editor in order to LSP load those files correctly and local testing becomes more difficult.
tigrato
force-pushed
the
tigrato/enable-kind
branch
from
44f8212 to
24215af
Compare
This PR re-enables the Kubernetes integrations tests using a KinD (Kubernetes in Docker) cluster. New steps have been introduced to GitHub's Integrations (Non-Root) Action that configure the KinD cluster using [`helm/kind-action`](https://github.com/helm/kind-action) and do some network configurations allowing the container where tests run to connect to the KinD control plane. This PR also fixes some of the tests and fixes a bug that affected joining operations when the target service was a legacy kubernetes proxy. Some improvements will be introduced in future patches to improve the logic and reduce the time required for the tests to run. Fixes #25539
tigrato
force-pushed
the
tigrato/enable-kind
branch
3 times, most recently
from
49b9af9 to
82b08c4
Compare
tigrato
force-pushed
the
tigrato/enable-kind
branch
from
82b08c4 to
ec37d32
Compare
public-teleport-github-review-bot
bot
removed request for
tcsc,
GavinFrazar and
smallinsky
This fixes an issue with verifying the cluster as being local when legacy proxy mode is used. Previsouly to this commit, all clusters in legacy mode were considered non-local which results in inconsistent behavior. This PR partially backports #25624
This PR re-enables the Kubernetes integration tests using a KinD (Kubernetes in Docker) cluster.
New steps have been introduced to GitHub's Integrations (Non-Root) Action that configures the KinD cluster using
helm/kind-actionand do some network configurations allowing the container where tests run to connect to the KinD control plane.This PR also fixes some of the tests and fixes a bug that affected joining operations when the target service was a legacy Kubernetes proxy.
Some improvements will be introduced in future patches to improve the logic and reduce the time required for the tests to run.
Fixes #25539