e2e test TestKamelCLIRun (Run with http dependency) consistently failing on OCP4 #3708
Comments
|
The default publishing strategy is S2I because it's on OpenShift but this feature uses Spectrum. I wonder if this combination is tested well. @johnpoth Do you know if it should work or not? |
|
OK, so we've been avoiding running the tests that upload jars to the registry on OpenShift, which means this feature is not (yet) supported on OpenShift, right? |
|
Hi @tadayosi ! Yes it works on OpenShift but you do have to extract the secret and trust it client side, so something like:
If we want to be fancy we can do it automatically in the Kamel CLI #3176 Thanks ! |
|
From @phantomjinx's log it actually fails from the Operator side so it might be that the Image registry's secret is not correctly configured during Operator Install. To confirm we could look into the full Maven build log from the Operator |
|
Here is the gist of the operator log. Line 2630 is the error executing the maven build. |
|
Thanks @phantomjinx ! I think this outputs only the last Maven repository used. To see the full list we'd have to run the Maven build on debug with the |
|
Ran the test with It appears that no attempt is made to download the maven dependency from the image-registry. |
|
Thanks @phantomjinx ! I thought there would be more info on debug regarding the connection to the Image Repository but it doesn't seem to be the case. Everything seems to be setup correctly so I suspect it's a cert issue but I'll have to reproduce locally to be sure. We can disable the test on OpenShift in the meantime. |
* Rather than trying to delete resources at the end of each sub-test, it is simpler and more reliable to generate a new namespace for each and have it deleted * The sampleJar URL is changed for the http dependency tests to avoid the request have to do a redirect. This improves the reliability of its retrieval * Sets the http dependency tests to problematic since on OCP4, the repositories are not being detected by the maven build causing test failures. See apache#3708.
|
Am wrapping up this and other changes in a set of commits that I'll post in a PR shortly. |
* Rather than trying to delete resources at the end of each sub-test, it is simpler and more reliable to generate a new namespace for each and have it deleted * The sampleJar URL is changed for the http dependency tests to avoid the request have to do a redirect. This improves the reliability of its retrieval * Sets the http dependency tests to problematic since on OCP4, the repositories are not being detected by the maven build causing test failures. See apache#3708.
* Rather than trying to delete resources at the end of each sub-test, it is simpler and more reliable to generate a new namespace for each and have it deleted * The sampleJar URL is changed for the http dependency tests to avoid the request have to do a redirect. This improves the reliability of its retrieval * Sets the http dependency tests to problematic since on OCP4, the repositories are not being detected by the maven build causing test failures. See apache#3708.
* Rather than trying to delete resources at the end of each sub-test, it is simpler and more reliable to generate a new namespace for each and have it deleted * The sampleJar URL is changed for the http dependency tests to avoid the request have to do a redirect. This improves the reliability of its retrieval * Sets the http dependency tests to problematic since on OCP4, the repositories are not being detected by the maven build causing test failures. See apache#3708.
* Rather than trying to delete resources at the end of each sub-test, it is simpler and more reliable to generate a new namespace for each and have it deleted * The sampleJar URL is changed for the http dependency tests to avoid the request have to do a redirect. This improves the reliability of its retrieval * Sets the http dependency tests to problematic since on OCP4, the repositories are not being detected by the maven build causing test failures. See apache#3708.
* Rather than trying to delete resources at the end of each sub-test, it is simpler and more reliable to generate a new namespace for each and have it deleted * The sampleJar URL is changed for the http dependency tests to avoid the request have to do a redirect. This improves the reliability of its retrieval * Sets the http dependency tests to problematic since on OCP4, the repositories are not being detected by the maven build causing test failures. See apache#3708.
* Rather than trying to delete resources at the end of each sub-test, it is simpler and more reliable to generate a new namespace for each and have it deleted * The sampleJar URL is changed for the http dependency tests to avoid the request have to do a redirect. This improves the reliability of its retrieval * Sets the http dependency tests to problematic since on OCP4, the repositories are not being detected by the maven build causing test failures. See #3708.
|
This issue has been automatically marked as stale due to 90 days of inactivity. |
The test can be found at https://github.com/apache/camel-k/blob/main/e2e/namespace/install/cli/run_test.go#L132
The command invoked is
kamel run --operator-id ${operatorID} -n ${ns} "../../../global/common/traits/files/jvm/Classpath.java" -d "https://github.com/apache/camel-k/raw/main/e2e/global/common/traits/files/jvm/sample-1.0.jar".See example failure log here.
Running the test locally, I can repeat the failure and found it is the integration kit that generates an error. This is due to the github dependency not being found:
I can confirm using verbose logging and adding some print statements that the process of downloading the jar dependency and uploading it as an image to the OCP4 registry is executed:
This test succeeds on
kind, although the type of registry being used is different (external v internal). Can we confirm that this logging looks correct? Any paths or hostnames that may be incorrect?Any thoughts, please comment. Thanks.
The text was updated successfully, but these errors were encountered: