allthingssecurity opened a new pull request, #27591: URL: https://github.com/apache/camel/pull/27591
# Description [CAMEL-25454](https://issues.apache.org/jira/browse/CAMEL-25454), follow-up to [CAMEL-24662](https://issues.apache.org/jira/browse/CAMEL-24662) #27216 by @gnodet made `camel kubernetes run` keep an explicit `--cluster-type` instead of replacing it with the detected type. @oscerd raised four follow-up points after the merge ([comment](https://github.com/apache/camel/pull/27216#issuecomment-6013311523)). This PR fixes them: 1. **`--cluster-type=k3s` with `--output` failed.** `KubernetesHelper.getKubernetesManifestPath()` mapped only Kind and Minikube to `kubernetes`, so K3S looked for `target/kubernetes/k3s.yml`. `KubernetesExport` builds every cluster type except OpenShift with the `kubernetes-maven-plugin`, which writes `kubernetes.yml`. The result was `FileNotFoundException: Unable to resolve Kubernetes manifest file type yml`. K3S now maps to `kubernetes` in `getKubernetesManifest()` and `getKubernetesManifestPath()`. The knative path still passes `service`. No other `ClusterType` value was affected. Before #27216 the detected type replaced `k3s`, so this only failed with `--disable-auto`. 2. **An explicit `--cluster-type=minikube` skipped the docker-env check and replaced explicit image options.** - Detection returns Minikube only when `MINIKUBE_ACTIVE_DOCKERD` and `DOCKER_TLS_VERIFY` are set. Otherwise it prints the `eval $(minikube docker-env)` hint. An explicit Minikube that builds with Docker and does not push now prints the same hint when those variables are not set. The defaults stay as they are. - The Minikube defaults (`docker`, no push) replaced an explicit `--image-builder` or `--image-push`, both for an explicit and for a detected Minikube. [CAMEL-21710](https://issues.apache.org/jira/browse/CAMEL-21710) says that an option the user sets turns off the automation for it. The two options of `kubernetes run` no longer have a picocli default (`--image-push` is now a `Boolean`). `detectCluster()` fills in the Minikube defaults only for the options that are not set, then falls back to `jib` and `true`. The defaults are now in the option descriptions. `--disable-auto` still turns off both detection and defaults. 3. **`explicitMinikubeClusterTypeShouldApplyDefaults` passed without the #27216 fix.** It set the Minikube env vars and the Minikube node, so detection returned Minikube anyway, and `createCommand()` forced `imagePush=false`. The test now has neither, and it leaves `--image-push` unset. With the `KubernetesRun` from before #27216 it fails with `expected: <minikube> but was: <kubernetes>`. 4. **Docs.** `discoverClusterType()` detects only OpenShift and Minikube, so the docs no longer say Kind is detected. They now say `--cluster-type=kind` must be set. The upgrade guide (4.23, `camel-jbang` section) explains the new `--cluster-type` and image option semantics. Tests: - `KubernetesHelperTest`: the manifest name for each `ClusterType`, plus `service` and no type. - `KubernetesRunClusterTypeTest`: the cluster type and the image defaults, by calling `detectCluster()`, which is now package-private. It covers explicit and detected Minikube with and without image options, the docker-env hint, `--disable-auto`, and explicit K3S. Neither class needs a Maven build or Docker, so both also run in CI. The run, export and delete test classes of this module are disabled in CI (`ci.env.name`). - `KubernetesRunCustomTest.explicitK3sClusterTypeShouldOutputKubernetesManifest`: `--cluster-type=k3s --output=yaml` end to end, including the Maven build of the exported project. Without the main-code change (run twice, the same both times; `detectCluster()` was made package-private only so the tests compile): ``` KubernetesHelperTest.manifestOfKubernetesMavenPlugin:40 expected: <target/kubernetes/kubernetes.yml> but was: <target/kubernetes/k3s.yml> KubernetesRunClusterTypeTest.detectedMinikubeKeepsImageBuilderSetByUser:104 expected: <jib> but was: <docker> KubernetesRunClusterTypeTest.explicitMinikubeKeepsImageOptionsSetByUser:92 expected: <jib> but was: <docker> KubernetesRunClusterTypeTest.explicitMinikubeWithoutDockerEnvPrintsHint:81 Expected the minikube docker-env hint, but the output was: ==> expected: <true> but was: <false> KubernetesRunCustomTest.explicitK3sClusterTypeShouldOutputKubernetesManifest:208 » FileNotFound Unable to resolve Kubernetes manifest file type `yml` in folder: target/tests/KubernetesRunCustomTest/route/target/kubernetes ``` Module tests run locally with the change: 134 tests, 97 passed, including all 9 of `KubernetesRunCustomTest`. 8 were skipped, because `KubernetesRunTest` and `KubernetesCommandTest` need Docker. 29 failed for a reason outside this change: the spring-boot runtime cases of `KubernetesExportTest` and `KubernetesExportKnativeTest` need `camel-catalog-provider-springboot:4.23.0-SNAPSHOT`, which my machine does not have. The same 29 fail in the same way on `main`. Not changed: `--output=json` fails for every cluster type, because JKube writes only `kubernetes.yml` and the run does not ask for JSON. That is left for a separate issue. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested the affected module, including the formatter, import-sort and jbang command doc generation. The regenerated `camel-jbang-kubernetes-run.adoc` and command metadata are committed. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
