I've got a Ruby project started with NetBeans, so the Rake file has been generated. Is there a way that I can run the project over the command line?
It runs fine when I use F6 through NetBeans, as does my automated test suite with Alt+F6. I'm essentially looking for something like...
$ rake run
Does this exist?
The goal of ruby programming is (generally) to either write a web application, or write a program that can be run from the command line.
For a web application a rake run option might be worthwhile, but really the most common web applicaition framework is Rails, and for rails, you can just run a dedicated webserver running your web app with script/server.
For a commandline program, just run whichever ruby file you have intended as the main file (the one with the code that runs at startup). Ruby doesn't have any of the difficulties that Java does (e.g. having a jar file with the right Main-class attribute, and getting the classpath right, etc...). So you don't really need a rake run target, because there's no complexity that needs to be hidden in the rakefile.
Although Ken's right, you can certainly make a rake task to run your program. In lib/tasks/project.rake:
namespace :project do
task :run do
call_your_code()
end
end
and then rake project:run will do what you want.
Related
I'm very new to Ruby, so, sorry if the answer is obvious.
Given
Existing project which consists exclusively of Cucumber tests (features). The project has a Gemfile, and env.rb under features/support which appends project directories to $LOAD_PATH and requires several libraries. I can run these tests by executing
bundler exec cucumber -r features
Question
I want to be able to load the support files into a REPL (say, pry), for the purposes of code inspection. In other words, I'd like to create a console -like script that loads up all the code that is used in the tests, but doesn't execute the tests. I need this for the editor that uses this kind of REPL for things like code completion, navigation, refactoring etc. Since this "application" doesn't have anything resembling an entry point, I'm at a loss as to how to create one. My efforts to require all files in the support directory so far had been unsuccessful, in particular, due to the use of World() top-level method, which I believe is defined by Cucumber.
I'm not quite sure what you're trying to accomplish but if you have say pry gem loaded in your Gemfile in test group, you should be able to just throw in a binding.pry command inside any test to inspect the code / environment.
Might look something like this:
Gemfile
group :development, :test do
gem "pry"
end
You could also use a rake task and load the environment taking the same approach.
lib/rake/sometask.rake
namespace :load do
desc "inspect code"
task :code, => :environment do
binding.pry
end
end
and run bundle exec rake load:code for example
I'm having some trouble testing a command line gem in a TeamCity build environment.
I'm working on a gem for building various types of manifest files, elf_manifesto. It runs from the command line and I've successfully tested it with Cucumber, and the really useful Aruba gem. Locally I'm working on a Lion MBP, using RVM, ruby 1.9.2. Everything's hunky dory.
The problem's arisen when moving the build process to the TeamCity environment at work. The TeamCity agent is running on a windows box and the problem seems to be that when triggering the command line executable from Aruba the script isn't found in the path environment on the windows box. Here's a snippet of Cucumber output from the build log.
[13:46:37]: [Scenario: Start manifesto with no parameters] When I run `manifesto`
[13:46:37]: [When I run `manifesto`] ChildProcess::LaunchError: The system cannot find the file specified. (2)
The Aruba gem is meant to take care of adding the executable (which is in the bin dir) to the path when running the tests. This works fine on my local set up, but fails on Windows. I've tried adding a RUBYPATH environment variable to the build parameters in TeamCity, but so far no luck.
Does anyone have any pointers?
Thanks in advance.
In my experience, Aruba does not add your gem from bin/ into the path. Even on UNIX-based projects, I've had to do it myself:
In env.rb:
PROJECT_ROOT = File.join(File.dirname(__FILE__),'..','..')
ENV['PATH'] = "#{File.join(PROJECT_ROOT,'bin')}#{File::PATH_SEPARATOR}#{ENV['PATH']}"
That being said, I have never gotten Aruba to work on Windows the same way as it did on UNIX.
To help diagnose, make use of the #announce tag on your features (which causes stderr and stdout to be printed), and possibly even drop in your own log statements in your custom steps.
In Windows, only if file with some extension like .COM,.EXE (and others) is executable.
You can change manifesto to ruby manifesto like with correct path to manifesto, it should work on windows.
If you want to work in Unix platform also, you need to change in support\env.rb for Aruba like below
require 'aruba/cucumber'
module ArubaOverrides
def detect_ruby(cmd)
processor, platform, *rest = RUBY_PLATFORM.split("-")
#puts platform
if platform =~ /w32$/ && cmd =~ /^manifesto /
"ruby -I../../lib -S ../../bin/#{cmd}"
else
"#{cmd}"
end
end
end
World(ArubaOverrides)
Hope it helps
You should be aware that Aruba runs the application it tests and creates all local output in its own working directory (awd). The awd defaults to tmp/aruba and is purged and created by Aruba at the beginning of every Scenario. However, the contents created by the last Scenario are left in the awd for your inspection.
Solution #1
Aruba will automatically add the bin directory of your project to the PATH environment variable for the duration of each Cucumber scenario.
You can create a bin dir under your project root, and copy you binaries there
Solution #2
You can use aruba-jbb, which provide a #no-aruba-tmpdir tag to handle this case.
What is the standard for testing while creating ruby gem?
Do most people run something like guard, or write tests and trigger them manually from the command line?
In Ruby there isn't really a "standard", instead people usually use what works well for them. If you don't like things like guard and prefer to run the tests from the command line, run the tests from the command line.
When I'm coding I run my tests manually from the command-line, but I also have a cron job that will run the tests against the latest commits and email the results every night.
I'm trying to execute cucumber tests for a project within a rake file in another project.
Currently I am trying this:
system "cd /path/to/project;rvm use --create 1.9.2-p290#test; cucumber features/test.feature"
This works for the cd, and the rvm seems to work if I run which ruby after the rvm use... but the problem is that the cucumber gem seems to be called from the current folder (not the app to test folder).
The error I get is:
cucumber is not part of the bundle. Add it to Gemfile. (Gem::LoadError)
It seems to be using the local gemset version of cucumber rather than the #test gemset.
Any thoughts on this?
Or is there a better way to run cucumber tests for another project that relies on rvm & a different bundle?
I've also been trying to do exactly the same thing; run an application's tests (or any rake task) from inside another 'control' application.
Reason: (just so I don't get served with a "why on earth?")
I am trying to build an application (rather like cruisecontrol.rb ) which can monitor, schedule and review the specs for a set of apps.
After some digging around in cruisecontrol's source I found that Bundler provides a solution;
Bundler.with_clean_env do
system "rake spec"
end
see line56 of https://github.com/thoughtworks/cruisecontrol.rb/blob/master/lib/platform.rb
That steps out of the bundle and the command is run without the control app's gems.
BUT as is most likely, the command uses bundle exec then this stops working.
Bundler.with_clean_env { system "bundle exec rake spec" }
And you are right back to the exact same problem. This is caused by some bundler variables still existing and being inherited by the sub-shell. Full (very good) explanation here.
The solution is to change the with_clean_env method on bundler like this;
BUNDLER_VARS = %w(BUNDLE_GEMFILE RUBYOPT BUNDLE_BIN_PATH)
module Bundler
def self.with_clean_env &blk
bundled_env = ENV.to_hash
BUNDLER_VARS.each{ |var| ENV.delete(var) }
yield
ensure
ENV.replace(bundled_env.to_hash)
end
end
above code from here
I put that in the environment.rb of my control application (it should probably be in a initializer?) and now I can run the specs of another app from within the control app.
#in control app
result = nil
Dir.chdir(test_app_path) #move into test app
Bundler.with_clean_env { result = `bundle exec rake spec` } #run test apps specs
puts result #display result inside control app
Changing the ; in your script to && seems to work.
I want to automate things like:
Creating a new Ruby on Rails application with pre-selected database, Git initialize it, create a Heroku project, commit all files, etc.
Upload all files in folder to another computer through SSH, but do not overwrite files.
Upgrade Ubuntu, install all basic packages through apt-get.
From what I understand, tools for this are Rake and Thor, however, which one should I use?
Rake seems to me more de-facto and popular. I have heard people recommending Thor.
How do these stand to each other in a rundown?
Rake and Thor serve different purposes.
Rake is a general build script tool that is project-specific. In other words, you put your rakefile into your project folder and in your project's source control, and you can create, build and do other automation tasks that are specific to your project in that rakefile. Rake requires a rakefile to run.
Thor is a general purpose command line scripting tool that makes it very easy to re-use scripts across many projects and to do project setup, etc., like you are suggesting. Thor allows you to "install" an executable script that you can call from anywhere on your system, similar to calling "ruby", "gem" or "rake" command lines. However, Thor's scripts are more suited to general purpose, cross-application automation because the Thor script does not rely on a file sitting in your project-specific folder. A Thor script is the entire script, packed and installed for re-use anywhere.
Based on your stated needs, you are better off using Thor because you will be able to install your script in one location and have it work anywhere on your system. You will not be bound to where a Rake file is sitting or anything like that.
By the way, Rails 3 uses Thor for pretty much everything that is not project specific. You still have a Rake file and you still run things like "rake db:migrate" or "rake test:units". Thor is used for things like "rails new ...", "rails server" and "rails generate ..." The use of Thor AND Rake in Rails 3 is the perfect illustration of where each of these tools is best suited.
For setting up Ubuntu chores, Chef might be a better option.
From their web site:
Chef is an open source systems integration framework, built to bring the benefits of server configuration management to your entire infrastructure.
It's written in Ruby and there are tons of Chef recipes/cookbooks. Chef will handle setting up Ubuntu and installing packages, servers, etc.
I don't know if you are working with virtual machines, but Vagrant will set up a virtual machine and then use Chef to configure it.
There is something important to mention here.
http://guides.rubyonrails.org/generators.html in its section 8 Application Templates.
You can execute git commands, select gems, capify project.
And you could also execute system commands to satisfy your last point: Upgrade Ubuntu, install all basic packages through apt-get.
I would go with puppet.
By the way, maybe vagrant is useful to you?