README.md in devinstall-1.2.2 vs README.md in devinstall-1.2.3

- old
+ new

@@ -1,14 +1,26 @@ -# Devinstall [![Gem Version][GV img]][Gem Version] +# Devinstall [![Gem Version][GV img]][Gem Version] [![Build status][Build img]][Build status] [![CodeClimate status][CodeClimate img]][CodeClimate status] [![Coverage Status][Coverage img]][Coverage Status] [Gem Version]: https://rubygems.org/gems/devinstall [GV img]: https://badge.fury.io/rb/devinstall.png +[Build status]: https://travis-ci.org/dragosboca/devinstall + +[Build img]: https://travis-ci.org/dragosboca/devinstall.png + +[CodeClimate Status]: https://codeclimate.com/github/dragosboca/devinstall + +[CodeClimate img]: https://codeclimate.com/github/dragosboca/devinstall.png + +[Coverage Status]: https://coveralls.io/r/dragosboca/devinstall?branch=master + +[Coverage img]: https://coveralls.io/repos/dragosboca/devinstall/badge.png?branch=master + This is a poor man automatic package builder / installer / deployer. -The build happens on a remote machine (in the future on several remote machines by package type) +The build is done on a remote machine (in the future on several remote machines by package type) via external tools rsync and ssh. The packages are installed on the remote machines also via external rsync/scp and sshsudo (until I will implement something more appropriate in Ruby) @@ -26,16 +38,16 @@ $ gem install devinstall ## Usage -When you install the gem, the installer automaticaly install a program named pkg-tool. +When you install the gem, the installer automatically install a program named pkg-tool. All the actions can be done via this tool. The general command line syntax is: - $ pkg_tool <action> [<package>] [--env <environment>] [--type <type>] [--config <config_file>] + $ pkg_tool <action> [<package>] [--env=<environment>] [--type=<type>] [--config=<config_file>] Where: ### Action can be one of the: @@ -43,11 +55,11 @@ Builds the package on the `build/env/host` and copy the package file(s) back in the `base/temp` folder install -Build (using `build` command) and install the builded package on the `install/env/host` +Build (using `build` command) and install the built package on the `install/env/host` tests Run the tests described in `test` section of the configuration file @@ -57,15 +69,18 @@ ### The switches The command line switches are: - --config: the config file (defaults to ./devinstall.yml) + --config=<config_file> + the config file (defaults to ./devinstall.yml) - --env: the environment for the install or upload action + --env=<environment> + the environment for the install or upload action - --type: only for –action build and specifies the package type (deb, rpm, tar.gz, arc....) + --type=<type> + the package type (`deb`, `rpm`, `tar.gz`, `arc`....) The switches override the defaults in the config file ## Example command: @@ -81,18 +96,18 @@ ## The config file In order to set all the variables and to define commands to do when building or installing you need a configuration file. -The said config file have simple YAML structure and should define the folowing parameters: +The said config file have simple YAML structure and should define the following parameters: local: folder: temp: The folder where the source/prepackaged files are on the local (developer) machine (`:folder`) and the -temporary folder where the generated packages will be downloades +temporary folder where the generated packages will be downloaded build: folder: command: provider: @@ -101,30 +116,30 @@ target: env: In order: - - the folder where the sources should be copied (might be ignored by some provider_plugins) + - The folder where the sources should be copied (might be ignored by some provider_plugins) - The command used to build the package (like `make package` or `dpkg-buildpackage`) - The provider for the build machine (like the `local` machine or another machine accessible only by SSH - `ssh` - - the package type ( `deb`ian, `rpm`, ...) + - The package type ( `deb`ian, `rpm`, ...) - - the architecture (might be ignored by some package_plugins) + - The architecture (might be ignored by some package_plugins) - - and the folder where the package builder will put the builded packages + - And the folder where the package builder will put the built packages - - env define an environment (lyke `prod` or `QA`) for which the package will be built / installed + - `env` define an environment (like `prod` or `QA`) for which the package will be built / installed Unlike the other parameters env is optional - install: + install: #<-- This is a section folder: - command: + command: #<-- This is a parameter provider: type: arch: env: repos: @@ -139,24 +154,24 @@ provider env: The parameters have the same meaning as for `build:` `repos` reffers to the package repository - `tests` is optional (DON'T do this) and no tests will be performend if it's missing + `tests` is optional (DON'T do this) and no tests will be performed if it's missing defaults: type: env: The default `type` and `env` if you don't use command-line switches The order in which the parameters will be searched is: - - local + - local: -Like: +Example: packages: <package_name>: <type>: <section>: # like build: or install: @@ -164,22 +179,26 @@ <parameter>: <value> - or global: -Like +Like: <section>: <env>: <parameter>: value -The parameters speciffied per package have priority over the global ones +The parameters specified per package have priority over the global ones In any case `env` is optional ## Contributing 1. Fork it 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Add some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create new Pull Request + + +[![Bitdeli Badge](https://d2weczhvl823v0.cloudfront.net/dboca/devinstall/trend.png)](https://bitdeli.com/free "Bitdeli Badge") +