Re: [Freecol-developers] test fail
Travis CI is a hosted continuous integration platform that is free for all open source projects hosted on Github. With just a file called .travis.yml containing some information about our project, we can trigger automated builds with every change to our code base in the master branch, other branches or even a pull request. These builds are triggered automatically when each developer checks in their code to the repository. It will run anything automatically that we declare. At the moment I have Travis automatically compiling, building, and running the unit test suite. This happens the moment I push updates to Github. We can also configure within the Travis file the ability to create distributions (packages) on a nightly/weekly basis, and have those uploaded to a destination (not back to the repo, but to Github releases, for example). Since it works automatically and without any manual intervention, It wouldn't create a dependency for that reason. Current ant task dist is failing because of: installer-translations: [java] Could not find net.sf.freecol.tools.InstallerTranslations. Make sure you have it in your classpath and freecol-git/build.xml:352: com.izforge.izpack.compiler.CompilerException: null:52: Resource not found: /Users/davlewis/ github.com/freecol-git/build/installer/lang.xml_cat Getting past those, there is also the following error produced by individual packages (e.g.: mydist -> mac): build.xml:504: java.lang.NoClassDefFoundError: org/apache/xml/serialize/OutputFormat David On Thu, Aug 31, 2017 at 3:34 PM Michael T. Pope wrote: > On Thu, 31 Aug 2017 17:30:15 + > David Lewis wrote: > > Yeah, the tests need a lot of love. I enabled the simpleMove test purely > > for the sake of using the client helper tests. Although those should be > > their own tests, I am still learning the system, so haven't created a > > client test yet. > > I am unconvinced that is going to provide much benefit. The client code > is likely to be race-prone, and thus difficult to make stable tests for. > The fact that we have only one (previously disabled) client test was > likely for good reason. OTOH there are many critical routines that would > benefit from small scale unit tests that require neither client or server > processes... lots of low hanging fruit that would really improve the test > suite coverage. > > > At the moment I'm cleaning up and fixing the build.xml file (creating a > new > > one for the time being) that will be designed to create packages from > > Travis and be deployed automatically so we don't have to do any of that > > manually. > > I am wary of adding travis as a build dependency. I am sure it is very > nice, but adding another step in the learning curve needs some > justification. Automatic package addition is not particularly > convincing. Adding packages is *very* rare. I think I have done it once. > > > There are a number of dependency issues that need to be solved > > before distributions can be made. I've figured out most of the errors, > and > > now just a matter of cleaning things up. There are a lot of legacy > settings > > in there. > > Not sure what you have hit here. Can you give an example? > > > Travis is currently only failing on 2 tests, it can't find the sound > mixer. > > Likely because it's a container. > > Looks like it to me. The SoundPlayer code is not very resilient. Feel > free to rework either it or the tests. I would be inclined to just disable > sound tests if AudioSystem.getMixerInfo returns no signs of a mixer being > present. > > Cheers, > Mike Pope > > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] test fail
On Thu, 31 Aug 2017 17:30:15 + David Lewis wrote: > Yeah, the tests need a lot of love. I enabled the simpleMove test purely > for the sake of using the client helper tests. Although those should be > their own tests, I am still learning the system, so haven't created a > client test yet. I am unconvinced that is going to provide much benefit. The client code is likely to be race-prone, and thus difficult to make stable tests for. The fact that we have only one (previously disabled) client test was likely for good reason. OTOH there are many critical routines that would benefit from small scale unit tests that require neither client or server processes... lots of low hanging fruit that would really improve the test suite coverage. > At the moment I'm cleaning up and fixing the build.xml file (creating a new > one for the time being) that will be designed to create packages from > Travis and be deployed automatically so we don't have to do any of that > manually. I am wary of adding travis as a build dependency. I am sure it is very nice, but adding another step in the learning curve needs some justification. Automatic package addition is not particularly convincing. Adding packages is *very* rare. I think I have done it once. > There are a number of dependency issues that need to be solved > before distributions can be made. I've figured out most of the errors, and > now just a matter of cleaning things up. There are a lot of legacy settings > in there. Not sure what you have hit here. Can you give an example? > Travis is currently only failing on 2 tests, it can't find the sound mixer. > Likely because it's a container. Looks like it to me. The SoundPlayer code is not very resilient. Feel free to rework either it or the tests. I would be inclined to just disable sound tests if AudioSystem.getMixerInfo returns no signs of a mixer being present. Cheers, Mike Pope pgpfOwcRAikgX.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] test fail
Travis is currently only failing on 2 tests, it can't find the sound mixer. Likely because it's a container. -- David [junit] Testcase: testSound(net.sf.freecol.common.sound.SoundTest): FAILED [junit] Could not construct sound player: Mixer unavailable. [junit] junit.framework.AssertionFailedError: Could not construct sound player: Mixer unavailable. [junit] at net.sf.freecol.common.sound.SoundTest.setUp(SoundTest.java:50) [junit] at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23) [junit] at junit.extensions.TestSetup$1.protect(TestSetup.java:23) [junit] at junit.extensions.TestSetup.run(TestSetup.java:27) [junit] [junit] [junit] Testcase: testClassic(net.sf.freecol.common.sound.SoundTest): FAILED [junit] Could not construct sound player: Mixer unavailable. [junit] junit.framework.AssertionFailedError: Could not construct sound player: Mixer unavailable. [junit] at net.sf.freecol.common.sound.SoundTest.setUp(SoundTest.java:50) [junit] at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23) [junit] at junit.extensions.TestSetup$1.protect(TestSetup.java:23) [junit] at junit.extensions.TestSetup.run(TestSetup.java:27) On Thu, Aug 31, 2017 at 10:29 AM David Lewis wrote: > Yeah, the tests need a lot of love. I enabled the simpleMove test purely > for the sake of using the client helper tests. Although those should be > their own tests, I am still learning the system, so haven't created a > client test yet. > At the moment I'm cleaning up and fixing the build.xml file (creating a > new one for the time being) that will be designed to create packages from > Travis and be deployed automatically so we don't have to do any of that > manually. There are a number of dependency issues that need to be solved > before distributions can be made. I've figured out most of the errors, and > now just a matter of cleaning things up. There are a lot of legacy settings > in there. > > David > > On Thu, Aug 31, 2017 at 3:31 AM Michael T. Pope > wrote: > >> On Thu, 31 Aug 2017 00:24:31 + >> David Lewis wrote: >> > That's odd... it succeeds on my local machine and local build machines >> > (docker containers), and succeeds on the Travis CI build servers (each >> run >> > `ant test`)... >> > >> > There are 2 tests that fail on the remote build nodes: mixer isn't >> > available on build nodes. But I don't see any NPE's. >> > I enabled the simpleMove test, which was disabled, and modified the >> client >> > connect helper significantly because it was broken. >> >> OK, AFAICT the client connect helper is *only* used for testSimpleMove, >> which is suggestive. I do not recall why simple move testing was >> disabled, but I suspect there is some lurking breakage. The test itself >> is a bit lame --- if we were really just testing the simple-move routines >> we could do a lot better job and without starting a client. So if we can >> not sort this out soonish I recommend just disabling it again. >> >> The fact that I am only seeing it on one machine (a new one) which >> otherwise has the same software setup as my usual development box suggests >> some sort of timing effect. >> >> > Can you try doing a clean checkout (or clone new repo) and try again? >> >> OK, when I get back to the machine that shows the failure. >> >> > Which version of of the JDK are you using? >> >> Java vendor: Oracle Corporation >> Java version: 1.8.0_141 >> Java WM name: OpenJDK 64-Bit Server VM >> Java WM vendor: Oracle Corporation >> Java WM version: 25.141-b16 >> >> Its always whatever the latest release on Fedora is, and thus is >> usually quite up to date. >> >> Looking again at the crash, it seems very entwined with the Locale >> setting, which is weird. I have tightened up the Locale handling >> (git.751b33d), perhaps that will help. >> >> Cheers, >> Mike Pope >> > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] test fail
Yeah, the tests need a lot of love. I enabled the simpleMove test purely for the sake of using the client helper tests. Although those should be their own tests, I am still learning the system, so haven't created a client test yet. At the moment I'm cleaning up and fixing the build.xml file (creating a new one for the time being) that will be designed to create packages from Travis and be deployed automatically so we don't have to do any of that manually. There are a number of dependency issues that need to be solved before distributions can be made. I've figured out most of the errors, and now just a matter of cleaning things up. There are a lot of legacy settings in there. David On Thu, Aug 31, 2017 at 3:31 AM Michael T. Pope wrote: > On Thu, 31 Aug 2017 00:24:31 + > David Lewis wrote: > > That's odd... it succeeds on my local machine and local build machines > > (docker containers), and succeeds on the Travis CI build servers (each > run > > `ant test`)... > > > > There are 2 tests that fail on the remote build nodes: mixer isn't > > available on build nodes. But I don't see any NPE's. > > I enabled the simpleMove test, which was disabled, and modified the > client > > connect helper significantly because it was broken. > > OK, AFAICT the client connect helper is *only* used for testSimpleMove, > which is suggestive. I do not recall why simple move testing was > disabled, but I suspect there is some lurking breakage. The test itself > is a bit lame --- if we were really just testing the simple-move routines > we could do a lot better job and without starting a client. So if we can > not sort this out soonish I recommend just disabling it again. > > The fact that I am only seeing it on one machine (a new one) which > otherwise has the same software setup as my usual development box suggests > some sort of timing effect. > > > Can you try doing a clean checkout (or clone new repo) and try again? > > OK, when I get back to the machine that shows the failure. > > > Which version of of the JDK are you using? > > Java vendor: Oracle Corporation > Java version: 1.8.0_141 > Java WM name: OpenJDK 64-Bit Server VM > Java WM vendor: Oracle Corporation > Java WM version: 25.141-b16 > > Its always whatever the latest release on Fedora is, and thus is > usually quite up to date. > > Looking again at the crash, it seems very entwined with the Locale > setting, which is weird. I have tightened up the Locale handling > (git.751b33d), perhaps that will help. > > Cheers, > Mike Pope > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] test fail
On Thu, 31 Aug 2017 00:24:31 + David Lewis wrote: > That's odd... it succeeds on my local machine and local build machines > (docker containers), and succeeds on the Travis CI build servers (each run > `ant test`)... > > There are 2 tests that fail on the remote build nodes: mixer isn't > available on build nodes. But I don't see any NPE's. > I enabled the simpleMove test, which was disabled, and modified the client > connect helper significantly because it was broken. OK, AFAICT the client connect helper is *only* used for testSimpleMove, which is suggestive. I do not recall why simple move testing was disabled, but I suspect there is some lurking breakage. The test itself is a bit lame --- if we were really just testing the simple-move routines we could do a lot better job and without starting a client. So if we can not sort this out soonish I recommend just disabling it again. The fact that I am only seeing it on one machine (a new one) which otherwise has the same software setup as my usual development box suggests some sort of timing effect. > Can you try doing a clean checkout (or clone new repo) and try again? OK, when I get back to the machine that shows the failure. > Which version of of the JDK are you using? Java vendor: Oracle Corporation Java version: 1.8.0_141 Java WM name: OpenJDK 64-Bit Server VM Java WM vendor: Oracle Corporation Java WM version: 25.141-b16 Its always whatever the latest release on Fedora is, and thus is usually quite up to date. Looking again at the crash, it seems very entwined with the Locale setting, which is weird. I have tightened up the Locale handling (git.751b33d), perhaps that will help. Cheers, Mike Pope pgpfENIAziDTS.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
