CukeQ notes

cukeq.markdown

Interface

cukeq-master --broker «host:port» --report-to http://«host:port» --scm {svn,git}://«url»

cukeq-slave --broker «host:port»

Master

1. REST service to trigger runs (payload: {:features => [file:line, file:line, ...]}).
2. Update from SCM.
3. Call Cucumber to get «exploded scenarios» (JSON) - (shell out to cucumber with custom formatter + --dry-run ??).
4. Create JSON payload {:run_id => id, :scm_rev => rev, :exploded_scenarios => [...]} (probably more..)
5. Put payload on jobs queue.
6. Pull step result from result queue.
7. POST step result to --report-to URL, or alternatively let reporters register themselves with the Master (webhookish).

Slave

1. Pull job from job queue.
2. If job revision != last revision
   • Update/checkout from SCM.
   • Restart Cucumber process with updated code files.
3. Invoke steps (through wire protocol?)
4. Put step result on result queue.

Other

• Webapp to trigger runs / show reports
• Can be triggered from command line (cukeq-runner file:line file:line, prints http://app/runs/«run id»)