I took a look at this issue, and the problem is that translation is not working properly in the Travis test setup.
A new migration was added that creates the default network barclamp deployment. In that migration, I initially used Barclamp::DEFAULT_DEPLOYMENT_NAME for the name of the deployment. I later used the same constant to look up the default deployment. This failed in the dev test environment because the I18n.t call was failing during the database migration and defaulting to "default", while it was succeeding in the I18n.t call while the unit tests were running, which caused it to try to look up a deployment with the name "Default". This caused the lookup to fail, and resulted in errors in the dev test environment that were identical to those seen in Travis. To work around this problem (I think translation failing during DB migration is probably understandable - correct me if you think otherwise), I hard coded the Deployment name to "Default" in the DB migration, and everything worked. What we are seeing in the Travis errors are exactly the opposite problem. The network barclamp default deployment name is hard coded to "Default" in the DB migration. When the Barclamp::DEFAULT_DEPLOYMENT_NAME constant is used while the unit tests are running, the I18n.t translation is failing and defaulting the name to "default". As a result, the deployment lookup by name fails which causes the unit tests to fail. At any rate, I can easily fix this by not using I18n.t() to get/set the name of the deployment, which is probably fine in this instance since the network barclamp can have only one deployment, and its name will most likely not be shown in the GUI as a result. But, I think we have a bigger issue here in that translation is not working when running unit tests on Travis. Unfortunately, I know very little about Travis or how translation is set up. Can anyone help out here? Thanks, Chris Dell From: Dearborn, Chris Sent: Wednesday, March 13, 2013 2:03 PM To: Hirschfeld, Rob; [email protected]; crowbar Subject: RE: [Crowbar] [Still Failing] crowbar/travis-ci-crowbar#60 (master - ac51708) Guys, I'm looking at this issue right now, and the problem is not an assert statement. Those were fixed in an earlier pull request. I know what the issue is and am working on an email now. Thanks, Chris From: crowbar-bounces On Behalf Of Hirschfeld, Rob Sent: Wednesday, March 13, 2013 2:01 PM To: [email protected]<mailto:[email protected]>; crowbar Subject: Re: [Crowbar] [Still Failing] crowbar/travis-ci-crowbar#60 (master - ac51708) Sigh .... I'll correct. Still working on the dev 1.9.3 migration over here. From: crowbar-bounces On Behalf Of James Tan Sent: Wednesday, March 13, 2013 12:54 PM To: crowbar Subject: Re: [Crowbar] [Still Failing] crowbar/travis-ci-crowbar#60 (master - ac51708) On 03/13/2013 06:38 PM, Travis-CI wrote: The build is still failing. Repository crowbar/travis-ci-crowbar Build #60 https://travis-ci.org/crowbar/travis-ci-crowbar/builds/5477613 Anyone looking into this failure on Ruby 1.9.3? Details here: https://travis-ci.org/crowbar/travis-ci-crowbar/jobs/5477618/#L562 Mostly an issue of incorrectly using "assert" when you really want to have "assert_equal". Please also run tests on Ruby 1.9.3, as Ruby 1.8.7 is going to be dropped by upstream in June. Thanks, James T.
_______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
