Integrate Testing Into CI

[WesGilster]

I was doing my build, but I ended with a compile error:

:compileJavaC:\Users\wgilster\git\Creation-Workshop-Host\host\src\org\area515\resinprinter\slice\SliceBrowser.java:42: error: cannot find symbol
import org.area515.resinprinter.stl.CheckSlicePoints;
                                   ^
  symbol:   class CheckSlicePoints
  location: package org.area515.resinprinter.stl
C:\Users\wgilster\git\Creation-Workshop-Host\host\src\org\area515\resinprinter\slice\SliceBrowser.java:44: error: cannot find symbol
import org.area515.resinprinter.stl.FillFile;
                                   ^
  symbol:   class FillFile
  location: package org.area515.resinprinter.stl
C:\Users\wgilster\git\Creation-Workshop-Host\host\src\org\area515\resinprinter\slice\SliceBrowser.java:45: error: cannot find symbol
import org.area515.resinprinter.stl.FillPoint;
                                   ^

Normally I wouldn't have made dependencies from my SliceBrowser into test code as that's pretty stupid, but since I thought you threw everything into a single jar anyway, I thought I'd take advantage of that. The compile issues above tell me that either we are missing test code in our build, or I'm missing something. Probably the latter, but I'm not sure how these builds are working quite.

[WesGilster]

On a different note... Do you have any idea if the side effects of disabling the Gradle Project Builder, are worse than the general instability of keeping it enabled? It pretty much breaks incremental builds, requires a project refresh every few couple of minutes and is continually rendering my tests unrunnable from the JUnit plugin. I don't want things to get worse, but my theory is that if it was disabled, it just wouldn't do anything.

[jmkao]

It shouldn't be necessary to run the project builder or BuildShip at all. All that's really necessary is to have run gradlew eclipse to set up the project dependencies. It would only need to be re-run if you add a new dependency to the build.

[jmkao]

The way the compile dependencies are set up, code in src cannot depend on code in tests.

Main and test sources and builds are segregated, but the dist is configured to package them together at the last step.

If you want to call tests from main, I can change the dependencies to allow that, but that might make things messy in the future.

[WesGilster]

No, your right I don't want to depend on test code, I threw that stuff together really quick and I just wanted it to work. I've since fixed that code so it doesn't depend on the test code. I've been thinking that the FullRelease runs all of our tests right after build, and before the release upload. It's seems like our FullRelease should fail the build if these tests aren't passing.

[jmkao]

FullRelease doesn't depend on the tests currently. My thinking was that since it's only for dev forks, it should obey the dev more than the process. I imagined that you might want to use fullRelease as the way of getting installs from a dev computer to a Raspberry Pi in a dev fork, and that not all tests might be passing when you need to do this.

For the releases generated by CI in area515, my intention is to have test failures fail the build. I'll be putting that in soon.

[WesGilster]

I see, I suppose that is a good point if I'm in a hurry to get my dev build on my Raspberry Pi.

[WesGilster]

I'm doing some cleanup here. Feel free to reopen, but I don't see this as an issue anymore.