← Back to team overview

cf-charmers team mailing list archive

Re: BLOCKER: CF Acceptance Test are incompatible with our Bundle

 

Matt, Tim, 

Do you have any concrete information about Yeti running successfully in cf-153 (CI report, anything)? It wouldn’t be productive to continue working on this if we don’t know for sure what the expected result should be.
If you don’t, then we can probably try to run them agains a cf-153 deployment with Bosh-Lite.


So far:
On Apr 24, 2014, at 11:07 AM, Alexander Prismakov <prismakov@xxxxxxxxx> wrote:

> rspec ./spec/apps/domain_spec.rb:20 # Domains can be used for an app's routes
> 
> rspec ./spec/apps/domain_spec.rb:45 # Domains when there are routes using the domain cannot be deleted
> 
> rspec ./spec/apps/info_spec.rb:42 # Dynamic app information can be queried for crashes
> 
> rspec ./spec/apps/java_java_web_spec.rb:23 # Simple::JavaJavaWeb tomcat validation
> 
> rspec ./spec/apps/large_app_spec.rb:24 # Large Applications an app that has large files that are not in the resource pool successfully uploads the large app
> 
> rspec ./spec/apps/lifecycle_spec.rb:11 # App lifecycle app serving web requests create/start/edit/stop/delete application
> 
> rspec ./spec/apps/lifecycle_spec.rb:77 # App lifecycle basic app is able to scale number of instances
> 
> rspec ./spec/apps/lifecycle_spec.rb:131 # App lifecycle app that dies of memory overdose correctly has events
> 
> rspec ./spec/apps/node_spec.rb:9 # Node node 0.6 starts the app successfully
> 
> rspec ./spec/apps/node_spec.rb:14 # Node node 0.6 supports git modules
> 
> rspec ./spec/apps/node_spec.rb:30 # Node node 0.6 supports native extensions via node-gyp
> 
> rspec ./spec/apps/node_spec.rb:9 # Node node 0.8 starts the app successfully
> 
> rspec ./spec/apps/node_spec.rb:14 # Node node 0.8 supports git modules
> 
> rspec ./spec/apps/node_spec.rb:30 # Node node 0.8 supports native extensions via node-gyp
> 
> rspec ./spec/apps/node_spec.rb:9 # Node node 0.10 starts the app successfully
> 
> rspec ./spec/apps/node_spec.rb:14 # Node node 0.10 supports git modules
> 
> rspec ./spec/apps/node_spec.rb:30 # Node node 0.10 supports native extensions via node-gyp
> 
> rspec ./spec/buildpacks/admin_buildpack_spec.rb:24 # Admin Buildpacks admin uploads a buildpack uses the uploaded buildpack
> 
> rspec ./spec/buildpacks/admin_buildpack_spec.rb:30 # Admin Buildpacks specifying an admin buildpack with --buildpack doesn't use any admin buildpack except the one whose name was specified
> 
> rspec ./spec/tools/imagemagick_spec.rb:25 # Tools::ImageMagick Deploy Ruby application that uses RMagick and ImageMagick tools
> 
> rspec ./spec/tools/loggregator_spec.rb:62 # Tools::Loggregator can tail app logs
> 
> 
> 
> -Alex P.
> 

Thank you.
Manuel



On Apr 24, 2014, at 9:27 AM, Manuel Garcia <mgarciap@xxxxxxxxx> wrote:

> Thank you Tim.
> 
> CATs was driving us crazy and we were spending way too much time on it. However, we learn some things about it for next milestones.
> 
> Let’s see how it goes with Yeti. We are behind our schedule with the CI environment.
> 
> 
> On Apr 23, 2014, at 10:45 AM, Tim Labeeuw <tlabeeuw@xxxxxxxxxxxxxxx> wrote:
> 
>> If you go to cf-release you should find the tests under https://github.com/cloudfoundry/cf-release/tree/v153/src/tests. Those are the compatible test suite. I think CATS is a latter addition at https://github.com/cloudfoundry/cf-release/tree/v162/src/acceptance-tests. Sorry I forgot to check which version CATS was introduced.
>> 
>> Tim
>> 
>> On Apr 23, 2014 6:10 AM, "Manuel Garcia" <mgarciap@xxxxxxxxx> wrote:
>> Hi guys, 
>> 
>> There is no tags/versions relationship between CF RELEASE and CF Acceptance Tests project.
>> 
>> Our current situation is that there is no way to make CATS work agains our Bundle (cf release 153) without us modifying CATS which does not make any sense at all.
>> You can take a look at James answer email below.
>> 
>> Alternatives:
>> A) Identify if passing tests are enough and custimize CATs to only run ‘compatible’ tests
>> B) Develop a very simple script to test the following CLI actions: target api, login, create org, create space, switch to space, push a our simple app example, curl and test output, delete app.
>> 
>> Action Items:
>> - Spend few hours with ‘A' only identifying if compatible tests are enough
>> - Share results and suggestion with the team 
>> 
>> Any comments, feedback will be much appreciated.
>> 
>> Manuel
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: Alexander Lomov <lomov.as@xxxxxxxxx>
>>> Subject: Re: [vcap-dev] Running latest CATs tests on CF v153.
>>> Date: April 23, 2014 at 7:03:53 AM GMT-3
>>> To: <vcap-dev@xxxxxxxxxxxxxxxx>
>>> Reply-To: <vcap-dev@xxxxxxxxxxxxxxxx>
>>> 
>>> Thank you, James. It really make sense. 
>>> 
>>> 
>>> 
>>> On 22 April 2014 20:28, James Bayer <jbayer@xxxxxxxxxxxxx> wrote:
>>> i appreciate the difficulty. there is a story under consideration to put CATS as a submodule of cf-release [1] so that you'll always know the compatible CATS version for the release # of cloud foundry you are using.
>>> 
>>> [1] https://www.pivotaltracker.com/story/show/69934952
>>> 
>>> 
>>> On Tue, Apr 22, 2014 at 8:15 AM, Alexander Lomov <lomov.as@xxxxxxxxx> wrote:
>>> Hi, all.
>>> 
>>> We've found an error in the way how latest CATs works with CF v153. The thing is that CATs creates names for orgs, users and apps with upper case. As I see CF v153 is designed to work with names that have lower case. To fix this issue I made some changes to CATs (https://github.com/allomov/cf-acceptance-tests/commit/0411c77e822ec1dd0eee3601169b75c8a9975e80#diff-b5c76fbd59b67a63c2e4080cbb9c7148L49) and after this changes we was able to run tests that was falling.
>>> 
>>> I see that the latest version of CATs is incompatible with CF v153, but CATs repo doesn't have any tags or references to cf release it supports. The question is about CATs version we need to use to validate our deployment. Do we need to checkout older version of CATs or we need to patch latest version? I guess I'll also write to vcap-dev google group about it?
>>> 
>>> 
>>> Thank you,
>>> Alex.
>>> 
>>> To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@xxxxxxxxxxxxxxxx.
>>> 
>>> 
>>> 
>>> -- 
>>> Thank you,
>>> 
>>> James Bayer
>>> 
>>> 
>>> To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@xxxxxxxxxxxxxxxx.
>> 
> 


References