| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To further support OTP releases I have added support for generating
application appup files. These include instructions that systools uses
to generate a relup file which contains the low level instructions
needed to perform a hot code upgrade. My goal with this module is to
produce "good enough" appup files or at least a skeleton to help one get
started with something more complex. If an appup file already exists for
an application this command will not attempt to create a new one.
Usage:
$ rebar generate-appups previous_release=/path/to/old/version
Generally this command will be run just before 'generate-upgrade'.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Add flags to rebar_utils:sh to control output and error handling.
Replace calls to os:cmd with calls to rebar_utils:sh.
|
| | |
|
| |
|
|
|
|
|
|
| |
Modify rm_rf and cp_r to work when {win32,_} = os:type().
Simplify rm_rf to only accept one filename, directoryname or wildcard.
Add unit tests to ensure a similar behaviour on windows and unix.
Thanks to tuncer for guidance and feedback.
|
| |
|
|
|
|
|
|
| |
Modules that include the EUnit header get an implicit test/0 fun,
which cover considers a runnable line, but eunit:(TestRepresentation)
never calls. Result: prod modules with tests can never reach 100%
coverage. Ironic. In this case, fix it by decrementing the NotCovered
counter returned by cover:analyze/3.
|
|
|
1. When running the eunit command with the convention of putting
tests in "*_tests" modules, eunit would run those tests twice. This
is because: 1) eunit:test/1 will naturally look for foo's tests both
in foo, and in foo_tests, and 2) eunit:test/1 was being folded over
all project modules. The fix is to filter "*_tests" modules from the
list passed to eunit:test/1.
2. When running the eunit command with cover enabled and tests in a
'test' directory, cover would error because it couldn't find the
source code for those tests. This is because cover:analyze/3 will
only find module source in "." and "../src". This is hard-coded in
cover :-(. Since cover shouldn't be calculating code coverage on test
code anyway, the fix is to not fold cover:analyze/3 over
non-production code.
3. When running the eunit command with cover enabled and a test suite
defined, cover would only attempt to calculate coverage on the the
test suite itself. This was because only the suite was passed to
cover:analyze/3. The fix is to fold cover:analyze/3 over all the
production code, filtering out the suite module if it is defined.
|
