How to run Gardener integration tests for shoot creation without production credentials?

Answer

To exercise the shoot creation logic in Gardener’s integration test suite while avoiding real cloud credentials, run the tests against a local Kubernetes cluster (e.g., kind) and configure Gardener to use a fake or test cloud provider. This keeps the test reproducible locally and does not expose any production secrets.

Confirmed steps

1. Create a local kind cluster (or use an existing envtest cluster):

   # Install kind if needed
   # go install sigs.k8s.io/kind@v0.22.0
   kind create cluster --name gardener-test --wait 60s
   export KUBECONFIG="$(kind get kubeconfig-path --name='gardener-test')"
   

2. Set Gardener to use a fake provider. The integration tests respect the environment variable GARDENER_TEST_PROVIDER (or GARDENER_CLOUD_PROVIDER for some providers) to switch to a mock implementation that does not call real APIs.

   export GARDENER_TEST_PROVIDER=local   # or "fake" depending on the provider code
   # For AWS‑style tests you can also provide dummy keys that are ignored by the fake provider:
   export AWS_ACCESS_KEY_ID=test
   export AWS_SECRET_ACCESS_KEY=test
   

3. Run the shoot‑creation focused test suite. Gardener’s Makefile provides a target that runs integration tests with a focus label; you can also invoke go test directly.

   # Using make (adjust the focus label as needed)
   make test-integration TEST_FOCUS=ShootCreation
   
   # Or directly with go test
   GO111MODULE=on go test ./test/integration/shoot -run TestShootCreation -v
   

4. Verify that no real cloud calls occur. Look in the test output for references to the kind control‑plane endpoint and absence of real provider URLs.

   # Example verification command after the test run
   grep -E 'kind-control-plane|127\.0\.0\.1' test-output.log
   # Ensure no lines contain real AWS, Azure or GCP endpoints
   

Likely explanation / assumptions

The Gardener integration test framework already contains a "local" or "fake" provider implementation that is exercised when GARDENER_TEST_PROVIDER is set. This provider creates shoot objects in the API server but does not attempt to provision real infrastructure; instead it patches the shoot status to simulate successful reconciliation. By pointing Gardener’s KUBECONFIG at a kind cluster, the API server and controller manager run locally, satisfying the requirement to exercise the controller logic without external credentials.

If the tests still fail because they expect provider‑specific configuration (e.g., region, zone), you can supply dummy values via the usual provider environment variables (AWS_REGION, AZURE_LOCATION, etc.). These values are ignored by the fake provider but satisfy any validation that expects them to be present.

When to ask for more detail

If you observe that the test logs still contain calls to real cloud endpoints after setting the fake provider, please share the exact error message or the provider name you are targeting; that information would change the recommendation (e.g., a different fake‑provider flag may be required).