Fix #696 Test HTTPS with the HTTP clients

[ppalaga]

No description provided.

[ppalaga]

19d506a moved the javax.net.ssl.trustStore related code to a separate QuarkusTestResourceLifecycleManager in integration-tests/support/test-support

I realized that I'll need to reuse it in the Telegram test

[ppalaga]

26add1e added the missing license header.

[ppalaga]

The the previous iteration failed due to some broken Maven download. bcf1262 is just a rebase to force a new build.

[ppalaga]

Strange, fails due to the same thing again, this time on Java 12. Does anybody have an idea how to proceed?

Could not transfer artifact org.apache.activemq:artemis-selector:jar:2.11.0 from/to central (https://repo.maven.apache.org/maven2): Connection timed out (Read failed)

[jamesnetherton]

Shouldn't this stuff be cached and restored on each PR?

Are the cache keys we use correct (I'm no expert here)? We have maven-${{ github.sha }}. Wont this cache the m2 repo for the commit SHA that triggered the GitHub action? I.e every commit on a PR forces the cache to be generated?

Would it not be better for the key to be based the content of the BOMs? E.g something like:

- uses: actions/cache@v1
  with:
    path: ~/.m2/repository
    key: ${{ runner.os }}-maven-${{ hashFiles('**/poms/**/*.xml') }}
    restore-keys: |
      ${{ runner.os }}-maven-

[lburgazzoli]

The cache is done using github.sha as key as we need to cache the result of the build so the native tests that happens after are based on the same artifacts generated by the build, otherwhise either you have to rebuild them or use snapshots but they may be not what you'd expect

[ppalaga]

The build-alternative-jvm job does not use the cache and indeed, it perhaps could to both finish faster and to (partly) avoid the download problems. I have a added a commit adding the cache.

I just learned that the GH actions' caches are immutable per entry, so consuming the cached repo from the build job in build-alternative-jvm should not have any influence on the itest jobs that also consume the same cache key.

[ppalaga]

Clearly, enabling the cache for build-alternative-jvm does not address the original problem with the download timeout. If that kind of issues persists, we should experiment with increasing the readTimeout http://maven.apache.org/guides/mini/guide-http-settings.html#Connection_Timeouts
and setting maven.wagon.http.retryHandler.requestSentEnabled=true https://github.com/apache/maven-wagon/blob/master/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L403-L412

[ppalaga]

Is this good to merge now that the CI is passing?