-
Notifications
You must be signed in to change notification settings - Fork 64
[java-source-utils] Fix regresion from 77c9c5fa #923
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
e58babe to
871c08c
Compare
Context: 77c9c5f Commit 77c9c5f introduced a regression in `tools/java-source-utils`, wherein the unit tests would fail, e.g. org.junit.ComparisonFailure: ../../../com/xamarin/JavaType.java Javadoc XML expected:<...um"> <javadoc>[<![CDATA[JNI sig: Lcom/xamarin/JavaEnum;]]></javadoc> … </m...> but was:<...um"> <javadoc>[ <![CDATA[JNI sig: Lcom/xamarin/JavaEnum;]]> Part of the problem is that this failure was *overlooked*; it's very common for PR builds to fail because mono SIGSEGVs, and we don't always take the time to restart failed PR builds to ensure that they're green (oops). The Windows builds, meanwhile, were green. Consequently, when commit 77c9c5f introduced a test failure in the `java-source-utils` unit tests, but we didn't see the failure. This "lack of seeing" is in part because we've become inured to test failures (mono SIGSEGVs), but also because the `java-source-utils` unit tests: 1. Are *only* run on the `mac_build` job, and 2. The results of the `java-source-utils` unit tests are not shown in DevOps' **Tests** tab. The only way to see the failure is to read the full **Mac - Mono** > **Run Tests** output, and know what you're looking for. Fix these two more fundamental issues: 1. Update `tools/java-source-utils/build.gradle` so that when `gradle test` is run, JUnit XML-formatted test result files are created. 2. Update `core-tests.yaml` so that the `java-source-utils` unit tests are executed. 3. Publish the XML files created between (1) and (2). This should ensure that future `java-source-utils` failures are appropriately seen and not ignored. I then ran a PR build without fixing anything, verifying that the **Tests** tab now shows the expected unit tests failures. Fix the `java-source-utils` unit test expected output, so that the `java-source-utils` unit tests pass once again…on macOS. They don't current pass on Windows, for currently unknown reasons (but probably line ending-related). We will enable Windows support later.
919704d to
8111369
Compare
8111369 to
e323693
Compare
This reverts commit e323693. We figured out what was going wrong: project configuration! Most of the build was as Release config, meaning e.g. `bin/BuildRelease/JdkInfo.props` was created, but the `java-source-utils` unit tests were run in Debug config, which meant it couldn't find `bin/BuildDebug/JdkInfo.props`, as it didn't exist. This meant that the wrong JDK was used for the tests, thus pain.
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
pjcollins
approved these changes
Dec 1, 2021
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: 77c9c5f
Commit 77c9c5f introduced a regression in
tools/java-source-utils,wherein the unit tests would fail, e.g.
Part of the problem is that this failure was overlooked;
it's very common for PR builds to fail because mono SIGSEGVs, and we
don't always take the time to restart failed PR builds to ensure that
they're green (oops). The Windows builds, meanwhile, were green.
Consequently, when commit 77c9c5f introduced a test failure in the
java-source-utilsunit tests, but we didn't see the failure.This "lack of seeing" is in part because we've become inured to test
failures (mono SIGSEGVs), but also because the
java-source-utilsunit tests:
Are only run on the
mac_buildjob, andThe results of the
java-source-utilsunit tests are notshown in DevOps' Tests tab.
The only way to see the failure is to read the full
Mac - Mono > Run Tests output, and know what you're
looking for.
Fix these two more fundamental issues:
Update
tools/java-source-utils/build.gradleso that whengradle testis run, JUnit XML-formatted test result filesare created.
Update
core-tests.yamlso that thejava-source-utilsunittests are executed.
Publish the XML files created between (1) and (2).
This should ensure that future
java-source-utilsfailures areappropriately seen and not ignored.
I then ran a PR build without fixing anything, verifying that the
Tests tab now shows the expected unit tests failures.
Fix the
java-source-utilsunit test expected output, so that thejava-source-utilsunit tests pass once again.