test: verifying test, lint, clirr, and graalvm in checks#456
test: verifying test, lint, clirr, and graalvm in checks#456suztomo merged 13 commits intogoogleapis:mainfrom
Conversation
|
This detected the #452 in the check. Good: |
The following simple Python script can generate the list
for j in [8, 11]:
for r in ["java-trace", "java-bigquery"]:
for t in ["test", "lint", "clirr"]:
print(' - "build (%s, %s, %s)"' % (j, r, t))
|
Warning: This pull request is touching the following templated files:
|
In this PR, I keep the existing required "dependencies" checks as they are, but this PR adds new checks as required. |
|
The GraalVM test failed because it didn't run with GraalVM: |
Note: probably I do not go for this option. I could setup GraalVM binary in GitHub Actions but this does not reflect what we would have in downstream repositories.
|
This ayltai/setup-graalvm is handy: Note: probably I might not go for this option to install GraalVM. I could setup GraalVM binary in GitHub Actions like this, but this does not reflect what we would have in downstream repositories, which use testing-infra-docker. How can we ensure the GraalVM version in testing-infra-docker and native-image-version from the shared config? (Maybe manually synching the version still works) |
|
action/checkout to v3 setup-java to v3 |
| - java-orgpolicy | ||
| steps: | ||
| - uses: actions/checkout@v2 | ||
| - uses: stCarolas/setup-maven@v4 |
| - uses: stCarolas/setup-maven@v4 | ||
| with: | ||
| maven-version: 3.8.1 | ||
| - uses: ayltai/setup-graalvm@v1 |
There was a problem hiding this comment.
@Neenu1995 @mpeddada1 Do we allow/ban this GitHub Actins?
There was a problem hiding this comment.
As long as it doesn't access our secrets we are fine with using any action. But this one looks like it is not being actively developed anymore. So may not be a good long term solution.
There was a problem hiding this comment.
Thanks. I'll use this then.
I see the owner maintains the repository. https://github.com/ayltai/setup-graalvm/commits/master
When we need alternative we can just use curl and unzip the content.
There was a problem hiding this comment.
My bad. I saw the last release was in May 2021. Looks like it is being being actively developed.
|
11 minutes to finish GraalVM test. Not too bad but I will revisit this long wait time by asking feedback among the devs here in few months. |
|
168cc88 should fail at the GraalVM test. As per @mpeddada1 , native-maven-plugin 0.9.11 and GraalVM 21.2.0 are incompatible. Let's see whether this new test can detect the incompatibility. |
|
Nice! It caught the incompatibility: |
|
@suztomo @Neenu1995 Is there any way we can keep this test consistent with the version in the testing-docker-infra? |
|
@mpeddada1 I don't think it's possible. I leave a comment in YAML file: https://github.com/googleapis/java-shared-config/pull/456/files#r837768926 If it's possible, then the question is which version of the container testing-docker-infra should this repository reference? Latest release, main, or certain versions. |
| # When a new version of native-maven-plugin fails to run in a downstream | ||
| # library, it's likely to be an incompatibility with the GraalVM version. | ||
| # In that case, you need to upgrade the Docker container used in the | ||
| # tests in the downstream repositories (not just this value below). | ||
| # Example: https://github.com/googleapis/testing-infra-docker/pull/195 | ||
| graalvm-version: 22.0.0.2 |
There was a problem hiding this comment.
Added an instruction on how to upgrade GraalVM version in testing-infra-docker.
The official page usually recommends being as specific as possible with the version tag. Yeah you're right, it might also be difficult to automate because there is a chance that the tag we specify won't be available on https://github.com/graalvm/container/pkgs/container/jdk. Manual upgrade sounds good for now! The comment will be helpful. |
|
If we want to use the exact same image in test-infra-docker, then we will have to move the tests to kokoro. But I don't think that is a direction we want to take. |



My attempt to run "test", "lint", and "clirr" in downstream tests. These checks ensure the maven-surefire-plugin, fmt-maven-plugin, and clirr-maven-plugin work as expected in the 2 client libraries (GAPIC and hand-written).
I don't intent to catch every failure cases in every downstream libraries, but I believe this setup will catch 90% of cases where plugin upgrades don't work in downstream repositories (and we would re-release the shared config again). Example: #452
CC: @Neenu1995
What if upgrading fmt-maven-plugin require adjusting Java code?
This PR changes the lint as a required check. This may introduce circular dependency.
For example, upgrading google-java-format to 1.15 requires code change in the downstream repository #452 (comment)
This require code change in the repository:
But we first would need to release the shared config before making the formatting change. How do we deal with it?
=> We can run
mvn com.coveo:fmt-maven-plugin:formatin the script to format the code before runningcom.coveo:fmt-maven-plugin:check: