clarify rspec usage (for example)

[seamusabshere]

(not that everybody uses rspec, but explaining how to use it would help people with other frameworks)

i have set io.fdy.cage.test: "rspec"

no arguments - works as expected

$ cage test myservice

first try (run) - failed

$ cage run frontend myservice rspec spec/requests/campaigns_controller_spec.rb
Error: Can only `run` pods with 1 service, frontend has 10

second try (exec) - failed

$ cage exec myservice rspec spec/requests/campaigns_controller_spec.rb
ERROR: No container found for myservice_1
Error: error running 'docker-compose -p myapp -f /Users/seamus/code/myapp/.cage/pods/frontend.yml exec myservice rspec spec/requests/campaigns_controller_spec.rb'

third try (test) - most logical, concise, but failed

you would expect it just appends the args to whatever is in io.fdy.cage.test

$ cage test myservice spec/requests/campaigns_controller_spec.rb
ERROR: Cannot start service myservice: oci runtime error: exec: "spec/requests/campaigns_controller_spec.rb": permission denied
Error: error running 'docker-compose -p myapptest -f /Users/seamus/code/myapp/.cage/pods/frontend.yml run --rm --no-deps myservice spec/requests/campaigns_controller_spec.rb'

fourth try (test) - works, but not super logical, or maybe it is

i guess it is logical if you consider test to set up the env, but not necessarily run the command

$ cage test myservice rspec spec/requests/campaigns_controller_spec.rb

Randomized with seed 28123
..................................................

[emk]

Just to clarify how it works right now, the test command you supply is used in the no arg case. When you pass a different command at the CLI, it currently takes precedence and replaces the command you supplied.

When debugging this or other problems, set RUST_LOG=cage::command_runner=debug and it will print the commands it's running.

[emk]

• "no arguments": This is working as designed.
• "first try (run) - failed": Two reasons why this failed: (1) you're trying to run tests in the dev environment, and (2) you're trying to run an individual container within a pod, which we don't support yet because it's a bit of anti-pattern that says your pod structure is a bit sketchy.
• "second try (exec) - failed": Two reasons why this failed: (1) you're trying to run tests in the dev environment, and (2) you're trying to run tests inside a currently running development container and you don't have your development environment up.
• "third try (test) - most logical, concise, but failed": What you're asking for here is basically --entrypoint for tests. Regular --entrypoint is already confusing, with lots of nasty edge cases, as seen here for example.
• "fourth try (test) - works, but not super logical, or maybe it is". Working as designed. This is the only version that attempts to runs code in the test environment and which doesn't require a custom equivalent of --entrypoint.

I've added new documentation for cage test --help that explains the first and last cases. Check it out here and let me know what you think: https://github.com/faradayio/cage/commit/4478390280a478cd32bdace6ba733472be24718b

[seamusabshere]

perfect!