I noticed that github pipelines, both on master and my PR started failing while building linux natives. Looks like the testPhantomTriangles
test is failing. Interestingly enough, the linux arm and android run just fine before hitting linux.
- For some reason, the linux natives build seems to be running a full engine build (With unit tests!)
- Which is weird, because there is a separate
BuildJmonkey
step for that.
- Which is weird, because there is a separate
- The exact exception, in that exact location, can only come from there not being an appropriate JmeSystemDelegate available. (Usually means that there is not
Jme3-desktop.jar
orJme3-android.jar
in the classpath.) - What changed? This used to work. Nothing was changed about the build scripts, either in the gradle files, nor the Github Actions definition. In fact, PR#1457, which was merged to create the current head, passed this exact same test as a separate branch…
- And, for clarity, the exact command-line that the workflow file runs works perfectly on my linux box…
Perhaps there was some change to the Ubuntu 18 test environment at GitHub.
I have created a personal branch in my forked repo to look into this further. See:
So far, I’ve confirmed:
- This has nothing to do with the natives, per se. It is not necessary to build the full engine/test suite when building the native code, and the location of the failure is a red herring.
- Also, not building the test suite when building the natives saves 4-5 min of compile time that is wasted because the later
BuildJmonkey
step re-runs these builds on all platforms anyway.
- Also, not building the test suite when building the natives saves 4-5 min of compile time that is wasted because the later
- This failure is only on Linux. When I dropped the
fail-fast
option on the build matrix, the Windows and Mac environments built just fine. See my latestactions
log.
Would it serve any purpose to open an issue on github at this time?
Are you able to build natives in a different Ubuntu test environment, such as Ubuntu 20?
virtual-environments/README.md at main · actions/virtual-environments · GitHub
After some testing:
-
Natives Build quite cheerfully on
ubuntu-18.04.5
andubuntu-20.04
- But not
unbuntu-16.04
(Apparently, a clang symlink does not work as expected)
- But not
-
JME java-land tests fail on every linux but
ubuntu-16.04
- Verified that the exact same java version is being used across images, both before and after this issue appeared.
There was an image update on Jan 11, 2021. I don’t know what github’s rollout schedule might be, but that is right about the correct timeframe to cause this. They do have a pre-release update of the image listed as of January 17 (Yesterday), so maybe this will just fix itself.
Hasn’t fixed itself as of the latest commit:
PBRLighting.j3md: correct a typographic error · jMonkeyEngine/jmonkeyengine@b08649b · GitHub
Since posting above, I did find a reference that it usually takes 3-4 days once an image is released as stable for it to percolate to the automatic runners. Also, no way to specify a release image in the workflow file.
I’ve been playing around in my branch a bit more, and am having an absolutely terrible time getting a copy of the build folders saved as an artifact on failure. (I want to see what files have already been built at that point)
I did some modified runs that set gradle logging to INFO
, and therefore got the standard error stream in the action log. (along with a lot of other stuff!) I was able to confirm that this is due to not being able to find a JmeSystemDelegate
by class name. Still probably a classpath issue.
Would it be worth filing an issue against the virtual environments repository? AFAIK, there are no weird classpath or directory shenanigans going on in the gradle files, so this should not be fragile…
Well, github rolled back the Jan 11 update, as it was causing issues for other users in other ways. Build is green again!
I expect this issue to come back when they move forward. To make it easier to help them troubleshoot if/when that happens, I’ve PR’d a few small changes to the workflow that simplify and focus the build just a bit.
Rationale for each change is in the PR coments.