grunt-boot-server-async
v0.2.0
Published
Boot the server asynchronously. Plugin completes task when server is fully booted, allowing execution against a running server.
Downloads
6
Readme
grunt-boot-rails-async
Boot a server asynchronously. Task completes when server is fully booted, allowing execution for your next grunt task.
Getting Started
This plugin requires Grunt ~0.4.4
If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:
npm install grunt-boot-server-async --save-dev
Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:
grunt.loadNpmTasks('grunt-boot-server-async');
The "boot_server_async" task
Overview
In your project's Gruntfile, add a section named boot_server_async
to the data object passed into grunt.initConfig()
.
grunt.initConfig({
boot_server_async: {
options: {
// Task-specific options go here.
},
your_target: {
// Target-specific file lists and/or options go here.
},
},
});
Options
options.separator
Type: String
Default value: ', '
A string value that is used to do something with whatever.
options.punctuation
Type: String
Default value: '.'
A string value that is used to do something else with whatever else.
Usage Examples
Default Options
In this example, the default options are used to do something with whatever. So if the testing
file has the content Testing
and the 123
file had the content 1 2 3
, the generated result would be Testing, 1 2 3.
grunt.initConfig({
boot_server_async: {
options: {},
files: {
'dest/default_options': ['src/testing', 'src/123'],
},
},
});
Custom Options
In this example, custom options are used to do something else with whatever else. So if the testing
file has the content Testing
and the 123
file had the content 1 2 3
, the generated result in this case would be Testing: 1 2 3 !!!
grunt.initConfig({
boot_server_async: {
options: {
separator: ': ',
punctuation: ' !!!',
},
files: {
'dest/default_options': ['src/testing', 'src/123'],
},
},
});
Example Usage
An example which starts a rails server.
The cwd
property indicates the directory in which you want to execute your command. It supports templates such as
<%= dirs.instrumentedE2E%> if that is defined in your initConfig object.
cmd
is the command used to start your server
matchString
is the string in stdout that indicates your server has fully started. This is used to determine when the
task has completed and then done() is called.
If you need to set any process environment variables, that assignment should be in an env
hash with the name of your
environment variables in caps such as GEM_SET
. As an example below, when booting a rails server, using cwd
to change
to the directory you want to boot up in is not enough to specify the gemset. The gemset does not get switched to properly
from global gemset to your application specific gemset so you have to explicitly set it here. This is what I found.
If there is a better way of doing it, please contribute.
grunt.initConfig({
dirs: {
// configurable paths
app: 'dev',
coverageE2E: 'coverage/e2e',
instrumentedE2E: '<%= dirs.coverageE2E %>/instrumented',
},
boot_server_async: {
rails: {
options: {
cwd: '<%= dirs.instrumentedE2E %>/dev/spec/dummy',
cmd: 'rails server',
matchString: 'Ctrl-C',
env: {
GEM_PATH: '~/.rvm/gems/ruby-1.9.3-p194@showroom_harmony_cms:~/.rvm/gems/ruby-1.9.3-p194@global'
}
}
}
});
Start a standalone selenium server:
grunt.initConfig({
boot_server_async: {
selenium: {
options: {
cmd: "webdriver-manager start",
matchString: 'Started org.openqa.jetty.jetty.Server', //the string to look for which signals server has successfully booted
}
}
});
Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using Grunt.
Release History
(Nothing yet)