-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
More Gradle follow-up, more focused on code analytics #3856
Conversation
…e output files go (and thus where they get accessed/scanned from) It turned out several places expected the old path in the build/classes dir, may be easier to restore old behavior like this until we're ready to rework Gradle further and make IDEs use it directly and/or re-integrate Gestalt and deeply examine its classpath scanning
… seems to matter, varies in engine vs module workspace)
Hooray Jenkins reported success with all tests good! |
Hooray Jenkins reported success with all tests good! |
Hooray Jenkins reported success with all tests good! |
Hooray Jenkins reported success with all tests good! |
Hooray Jenkins reported success with all tests good! |
Tested by several others and tweaked some more. Passed in Jenkins via our test org jobs. #3859 submitted to not forget some of the potentially problematic automated tests. More analytics visualizations enabled and showing in the new Jenkins now. Tried to hook up the Sonar cloud scanner again as well (got an earlier experimental branch), but that may need a bit more work and API additions to create module projects and such automatically, plus it ends up doubling the build duration as I guess the Sonar site builds the project from scratch (at least LGTM runs in parallel) |
Although it may also hold some promise in fixing some quirks due to how with Gradle 6 we got a new default target build path (
build/classes/java/main
instead of plainbuild/classes
) - turned out there were more places where that mattered than the few I found and tried to apply fixes for.This PR specifically fixes the ModuleTestingEnvironment, which for some reason failed to find any world generators as the test for which module provided one would run into one path with the
java/main
fragment and one without.I tried to puzzle that out for a while but didn't really get anywhere. This solution may not be perfect (somewhat going backwards) but it reduces uncertainties while we improve stuff further and find the time to make more proper fixes. I expect a next big round might be when we switch 100% to Gradle vs using any IDE-specific stuff.
This restores how Gradle and IntelliJ builds to the same paths (both regular source and test source, to a different spot each) so that in theory stuff should work the same via Gradle as in IntelliJ (... and good luck with Eclipse or Netbeans). Ultimately we should delegate all building, run configs, etc to Gradle, at which point we might be able to fix some of these quirks. Others may take some classpath tweaking in Gestalt - maybe delay that till the reintegration of the latest release?
Goes with:
Outstanding:
TypeRegistryTest
intermittently stall for me, both in Gradle and in IntelliJ. Sometimes I've been able to run the first one to completion even if it stalls for a minute or two, other times they just hang. Anybody else able to try it out on other OSes might be informative (I'm on Win10)LocalChunkProvider.checkForUnload()
- huh? Not sure that'd relate to these changes.ClientConnectionTest
andExampleTest
- the others work fine now.Pinging @DarkWeird for possible interest