Commit graph

16 commits

Author SHA1 Message Date
Tuncer Ayaz
4f41e742d3 rebar_eunit_tests: avoid repetition 2011-08-07 16:21:43 +02:00
Tuncer Ayaz
e3fe1c6903 rebar_eunit_tests: check return values 2011-08-07 16:21:40 +02:00
Tuncer Ayaz
5f2930b701 Fix whitespace errors in unit tests 2011-08-05 01:52:33 +02:00
Tuncer Ayaz
e21166ae6f Sync rel/files in dummy project with templates 2011-07-18 18:58:20 +02:00
Tuncer Ayaz
25c0226ab9 Update runner script in test project 2011-03-04 19:39:45 +01:00
joewilliams
11bf6b4aab Add 'generate-appups' command
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'.
2011-02-15 18:33:18 +01:00
Tuncer Ayaz
c466076ffb Clean up emacs file local variables 2011-01-31 17:55:36 +01:00
Tuncer Ayaz
1ee21c523f Update nodetool in upgrade_project 2011-01-31 17:55:02 +01:00
Tuncer Ayaz
b18194e24d Fix file existence checks 2011-01-29 17:37:15 +01:00
joewilliams
5298e93a18 Add 'generate-upgrade' command
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.
2011-01-27 18:37:39 +01:00
Tuncer Ayaz
e4036cbe56 Apply Tidier suggestions 2011-01-13 17:39:14 +01:00
Juhani Rankimies
52ca7795fe Unify executable invocation
Add flags to rebar_utils:sh to control output and error handling.
Replace calls to os:cmd with calls to rebar_utils:sh.
2011-01-06 15:02:19 +01:00
Juhani Rankimies
80c065191f Port rebar_eunit_tests to Windows 2010-10-27 11:39:12 -06:00
Juhani Rankimies
fd5ebe69a4 Port rebar_file_utils to Windows
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.
2010-10-27 11:39:12 -06:00
Chris Bernard
4825353a23 Fix incorrect coverage count when prod modules include EUnit header.
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.
2010-05-15 15:09:45 -04:00
Chris Bernard
25538e071f Fixed 3 bugs in rebar_eunit. Added EUnit tests to capture them.
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.
2010-03-04 20:53:12 -05:00