Updated doc regarding bundle usage
Allowing to get a shared ruby library directory will make things faster for people running tests on multiple modules all the day. Change-Id: Ia8d20cf0a33b2b38c0fe566b9e60f978378e0aa4
This commit is contained in:
@@ -35,9 +35,7 @@ bundler as well as rubygems (and ruby) are already installed on the system.
|
|||||||
.. |syntax| replace:: *syntax*
|
.. |syntax| replace:: *syntax*
|
||||||
.. code-block:: bash
|
.. code-block:: bash
|
||||||
|
|
||||||
mkdir vendor
|
bundle install --path ~/vendor/bundle # install all deps in ~/vendor/bundle
|
||||||
export GEM_HOME=vendor
|
|
||||||
bundle install
|
|
||||||
bundle exec rake lint # Run puppet-lint
|
bundle exec rake lint # Run puppet-lint
|
||||||
bundle exec rake syntax # Syntax check Puppet manifests and templates
|
bundle exec rake syntax # Syntax check Puppet manifests and templates
|
||||||
bundle exec rake spec # Run spec tests in a clean fixtures directory
|
bundle exec rake spec # Run spec tests in a clean fixtures directory
|
||||||
@@ -48,11 +46,43 @@ This relies on the Puppetfile to install all of the external modules
|
|||||||
required for testing. The url in this file uses the git:// protocol, so this
|
required for testing. The url in this file uses the git:// protocol, so this
|
||||||
may need to be updated if you are behind a proxy.
|
may need to be updated if you are behind a proxy.
|
||||||
|
|
||||||
|
Please note you might need to install some system dependencies in order to
|
||||||
|
allow bundle to install the gems.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
The ~/vendor/bundle directory will contain all the dependencies, and can be shared with
|
||||||
|
multiple projects. Doing so avoids duplication.
|
||||||
|
|
||||||
|
In case you don't want shared libraries, please do the following::
|
||||||
|
|
||||||
|
mkdir vendor
|
||||||
|
export GEM_HOME=vendor
|
||||||
|
bundle install
|
||||||
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Be advised that your local run can be successful and you can get a -1 from
|
Be advised that your local run can be successful and you can get a -1 from
|
||||||
Jenkins, because you only run the tests for your Operating System Family.
|
Jenkins, because you only run the tests for your Operating System Family.
|
||||||
|
|
||||||
|
Tiny trick for RSpec
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
You might find the time really long while running the tests. Part of the time is
|
||||||
|
due to the collection of the required puppet modules for the tests. The cache
|
||||||
|
directory is cleaned after each (successful) run, and if you're doing multiple changes
|
||||||
|
with an RSpec run between each, you'd want to keep that cache. This can be done like
|
||||||
|
that:
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
bundle exec rake spec_prep # download all the dependencies
|
||||||
|
bundle exec rake spec_standalone # actually run the test and keep cached modules
|
||||||
|
|
||||||
|
|
||||||
|
The modules are downloaded and cached in the *spec/fixtures/modules/* directory
|
||||||
|
|
||||||
The best reference for getting started with rspec-puppet can be found here_.
|
The best reference for getting started with rspec-puppet can be found here_.
|
||||||
|
|
||||||
.. _here: http://rspec-puppet.com/
|
.. _here: http://rspec-puppet.com/
|
||||||
|
Reference in New Issue
Block a user