Ádám pointed out the 16 test failures were related to business events. Doing some shotgun debugging I spun up and configured an activemq server, changed some more env vars like those matching FINERACT_EXTERNAL_EVENTS_*, re-started my Fineract server, and re-ran ExternalBusinessEventTest only (using a gradle --tests filter). All tests in that class passed. But Ádám wasn't convinced this was a proper solution and after poking around a bit, I agree. .github/workflows/build-postgresql.yml doesn't start up an activemq server (and every GitHub job uses a new VM <https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#using-a-github-hosted-runner>). I tried running integration tests again anyway (the 3rd gradle command), and started seeing failures related to spring/JMS from ApiVerificationTest. So I figure I can't have both JMS providers, or something like that.
I went back to build-postgresql.yml and started again, this time planning to let the integration tests start cargo instead of starting my own Fineract server. I suddenly started getting unapproved license failures just trying to run gradle build. I couldn't figure out the cause and I didn't remember what directly preceded these failures nor which/if leftover files from a previous build were sitting around <https://github.com/apache/fineract/pull/545>, so I worked around it with a heavy-handed git clean -fdx. After that, gradle build worked again, so did the rest of the build steps, and *all tests passed*. 🎉 Here's a step by step recap: 1. I opened a fresh terminal and did NOT set any Fineract-related environment variables. I figured I shouldn't need any since my postgres was using default values, and cargo will start up Fineract with the correct configuration for testing. 2. I ran all this against the tip of develop (26bc89ed59): gradle dropPGDB -PdbName=fineract_default gradle dropPGDB -PdbName=fineract_tenants gradle createPGDB -PdbName=fineract_tenants gradle createPGDB -PdbName=fineract_default gradle build -x cucumber -x test -x doc gradle cucumber -x :fineract-e2e-tests-runner:cucumber gradle test -x :twofactor-tests:test -x :oauth2-test:test :fineract-e2e-tests-runner:test -PdbType=postgresql gradle :twofactor-tests:test -PdbType=postgresql gradle :oauth2-tests:test -PdbType=postgresql You'll notice I'm again using slightly different commands than they appear in build-postgresql.yml. I already mentioned gradle vs. ./gradlew, so I'll explain the missing --no-daemon flags: After all those (and many more) gradle invocations I noticed much faster startup times with the gradle daemon <https://docs.gradle.org/current/userguide/gradle_daemon.html>. Why *do* we use --no-daemon so often? They recommended using the daemon for CI and dev machines. Note: I saw cargo was still running after gradle test so I manually killed that java process. Next questions: why do the tests fail when running against a Fineract server I start by hand (w/gradle devRun)? Does it matter? With cargo the tests are about *25% slower* (1hr w/cargo vs. 45min w/devRun), but otherwise all I'm trying to do here is reliably reproduce test results, so I think I'm fine sticking with the supported way to run integration tests rather than the faster way (although getting that 15min back every time would be nice, and if you factor in everyone running this...). On Wed, Jan 29, 2025 at 3:15 PM Adam Monsen <amon...@mifos.org> wrote: > I actually tried again with devRun-started backend. Same result (16 > failures), so at least I have something reproducible! > > I'm also re-running tests using a server started with bootRun in case >> that's any different from devRun. >> >
