| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
As discussed here
http://erlang.org/pipermail/erlang-questions/2012-December/071135.html
change the reltool spec to use the default sys-level mod_cond setting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When developing Riak, we have found bugs and other issues due
to the number of platforms we support.
Here is an overview of the changes:
- Fix command-line syntax for commands to work on *BSD / Sun
- Add chkconfig and getpid to nodetool
- Replace platform specific 'kill' commands with a nodetool
getpid method
- Fix RUNNER_USER settings to work on *BSD
|
|
|
|
|
| |
This allows the node to run in paths which include special characters,
for example 'C:\Program Files (x86)\Product Name'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch contains two additions to simplenode.runner:
1. Check if vm.args exists in CWD; if so, use it. This makes it
easier to start multiple concurrent nodes on a single machine
from one rebar-created release (starting each node from its
own directory, with its own copy of vm.args and e.g.
sys.config, log directory, database directory, etc.)
2. Add the targets start_boot <file> and console_boot <file>.
This is used to select a different boot script. The 'setup'
application (http://github.com/esl/setup) builds a special boot
script for installation (all apps loaded but not started,
making it possible to run install hooks with the full code path
in place).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
* Typos and other minor bug fixes
* Add "attach" command (via -remsh)
* Add "upgrade" command to install a hot upgrade package
* Add "upgrade" subcommand to UNIX runner script as well
|
| |
|
| |
|
|
|
|
|
|
| |
bin/<release_name> console -kernel test '[{"a","b"}]' fails, because
when $@ is inserted into CMD [{"a","b"}] is interpreted.
Fix the same issue for 'start' command and quote all arguments.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Args provided by erlsrv.exe were being mostly
discarded due to being processed through set_trim
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
app.config has been a long standing erroneous file in rebar. Erlang/OTP
documentation suggests a sys.config file instead. This file is stored in
the releases/VSN directory. This does a few things but most importantly
it ensures your config (contained in the application environment)
survives a hot upgrade. It also has the advantage of allowing the
configuration of the application to be versioned along side the
application code. This patch flips rebar to use sys.config rather than
app.config.
Additionally it makes this flip to vm.args as well, making them
versioned just like sys.config.
This patch also includes runner script changes to support the old
etc/app.config config file location and support for Windows.
Thanks to mokele for the initial work and kick in the pants to make this
finially happen.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Currently with default simplenode template, `appname console other_args`
will pass ["console", "other_args"] as plain arguments. But
`appname start other_args` effectively calls `appname console`. This
patch replaces this call with `appname console other_args`.
|
| |
|
| |
|
|
|
|
|
|
|
| |
`init:get_plain_arguments()` returns `["console", "more_args"]` when
started with `$APP_NAME console more_args`, but `["console"]` when
started with `$APP_NAME start more_args`. This patch makes `start`
behave like `console` in this respect.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a simple common_test suite template
that can be instantiated with the name of a module
under test like so:
`rebar create template=ctsuite testmod=mymodule`
The template creates an empty test suite in the test
directory, automatically exports test functions and
sets up a first, skipped test function.
|
|
|
|
|
| |
The trailing slash for PIPE_DIR is necessary for
both start and attach operations.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support OTP release upgrades I have added support for building
upgrade packages. Support for this is included in the
rebar_upgrade module, specifically generate_upgrade/2. It requires
one variable to be set on the command line 'previous_release' which
is the absolute path or relative path from 'rel/' to the previous
release one is upgrading from. Running an upgrade will create the
needed files, including a relup and result in a tarball containing
the upgrade being written to 'rel/'. When done it cleans up the
temporary files systools created.
Usage:
$ rebar generate-upgrade previous_release=/path/to/old/version
This also includes a dummy application that can be used to test
upgrades as well as an example.
Special thanks to Daniel Reverri, Jesper Louis Andersen and
Richard Jones for comments and patches.
|
| |
|
| |
|