rbcli 0.1.10 → 0.2.0

data/docs-src/docs/advanced/automatic_updates.md

@@ -0,0 +1,42 @@
+# Automatic Updates
+
+RBCli can automatically notify users when an update is available. If `force_update` is set (see below), RBCli can halt execution until the user updates their application.
+
+Two sources are currently supported: __Github__ (including Enterprise) and __RubyGems__.
+
+## GitHub Update Check
+
+The GitHub update check works best when paired with GitHub's best practices on releases, where new releases are tagged on master with the format __vX.X.X__. See [Github's release documentation][github_release_documentation] to learn more.
+
+RBCli will check your github repo's tags and compare that version number with one specified in your application at `config/version.rb`.
+
+```ruby
+autoupdate github_repo: '<your_user>/<your_repo>', access_token: nil, enterprise_hostname: nil, force_update: false, message: nil
+``` 
+The `github_repo` should point to the repo using the `user/repo` syntax. 
+
+The `access_token` can be overridden by the user via their config file, so it can be left as `nil` if you enable [Userspace Configuration][userspace_configuration]. The token is not needed at all if using a public repo. For instructions on generating a new access token, see [here][github_generate_token]. 
+
+The `enterprise_hostname` setting allows you to point RBCli at a local GitHub Enterprise server.
+
+Setting `force_update: true` will halt execution if an update is available, forcing the user to update.
+
+The `message` parameter allows setting a custom message that will be displayed when an update is available. Leaving it as `nil` will use the default message provided by RBCli.
+
+## Rubygems.org Update Check
+
+The Rubygems update check will check if there is a new published version of the gem on Rubygems.org. The latest published version is compared to the version number you configured RBCli with.
+
+```ruby
+autoupdate gem: '<your_gem>', force_update: false, message: nil
+```
+
+The `gem` parameter should simply state the name of the gem.
+ 
+Setting `force_update: true` will halt execution if an update is available, forcing the user to update.
+
+The `message` parameter allows setting a custom message that will be displayed when an update is available. Leaving it as `nil` will use the default message provided by RBCli.
+
+[github_release_documentation]: https://help.github.com/articles/creating-releases/
+[userspace_configuration]: user_config_files.md
+[github_generate_token]: https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/

data/docs-src/docs/advanced/command_types.md

@@ -0,0 +1,144 @@
+# Advanced Command Types
+
+RBCli has three different command types:
+
+* __Standard Commands__ (Ruby-based)
+* __Scripted Commands__ (Ruby+Bash based)
+* __External Commands__ (Wrapping a 3rd party application)
+
+
+This document is provided to be a reference. If you would like an in-depth tutorial, please see [Your First Command][your_first_command].
+
+
+## General Command Structure
+
+Commands in RBCli are created by subclassing `Rbcli::Command`. All commands share a certain common structure:
+
+```ruby
+class List < Rbcli::Command                                                           # Declare a new command by subclassing Rbcli::Command
+	description 'TODO: Description goes here'                                           # (Required) Short description for the global help
+	usage <<-EOF
+TODO: Usage text goes here
+EOF                                                                                   # (Required) Long description for the command-specific help
+	parameter :force, 'Force testing', type: :boolean, default: false, required: false  # (Optional, Multiple) Add a command-specific CLI parameter. Can be called multiple times
+
+	config_default :myopt2, description: 'My Option #2', default: 'Default Value Here'  # (Optional, Multiple) Specify an individual configuration parameter and set a default value. These will also be included in generated user config.
+                                                                                      # Alternatively, you can simply create a yaml file in the `default_user_configs` directory in your project that specifies the default values of all options
+end
+```
+
+* `description`
+	* A short description of the command, which will appear in the top-level help (when the user runs `mytool -h`).
+* `usage`
+	* A description of how the command is meant to be used. This description can be as long as you want, and can be as in-depth as you'd like. It will show up as a long, multi-line description when the user runs the command-sepcific help (`mytool list -h`).
+* `parameter`
+	* Command-line tags that the user can enter that are specific to only this command. We will get into these in the next section on [Options, Parameters, and Arguments][parameters_documentation]
+* `config_default`
+	* This sets a single item in the config file that will be made available to the user. More information can be found in the documentation on [User Config Files][user_config_documentation]
+
+## Standard Commands
+
+Standard commands are written as ruby code. To create a standard command called `list`, run:
+
+```bash
+rbcli command --name=list
+#or
+rbcli command -n list
+```
+
+A standard command can be identified by the presence of an `action` block in the definition:
+
+```ruby
+class List < Rbcli::Command
+	action do |params, args, global_opts, config|
+		# Code goes here
+	end
+end
+```
+
+Your application's __parameters__, __arguments__, __options__, and __config__ are available in the variables passed into the block. For more information on these, see [Options, Parameters, and Arguments][parameters_documentation].
+
+
+## Scripted Commands
+
+Scripted commands are part Ruby, part Bash scripting. They are a good choice to use if you feel something might be easier or more performant to script with Bash, or if you already have a Bash script you'd like to use in your project. You can create one with:
+
+```bash
+rbcli script -n list
+```
+
+This will create two files in your RBCli project: a Ruby file with the common command declaration (see [General Command Structure](#general-command-structure)), and a bash script in the folder `application/commands/scripts/`.
+
+You can tell a command is a script by the line:
+
+```ruby
+class List < Rbcli::Command
+	extern path: :default                                                              # (Required): Do not edit this line. Do delete it if you wish to manually specify a script path and set environment variables.
+end
+```
+
+RBCli will pass along your applications config and CLI parameters through JSON environment variables. To make things easy, a Bash library is provided that makes retrieving and parsing these variables easy. It is already imported when you generate the command, with the line:
+
+```bash
+source $(echo $(cd "$(dirname $(gem which rbcli))/../lib-sh" && pwd)/lib-rbcli.sh)
+``` 
+
+This will find the library which is stored on the system as part of the RBCli gem.
+
+You can then retrieve the values present in your variables like such:
+
+```bash
+rbcli params
+rbcli args
+rbcli global_opts
+rbcli config
+rbcli myvars
+
+echo "Usage Examples:"
+echo "Log Level:  $(rbcli config .logger.log_level)"
+echo "Log Target: $(rbcli config .logger.log_target)"
+echo "First Argument (if passed): $(rbcli args .[0])"
+```
+
+For your convenience, the script will have all the instructions needed there. For more instructions on how to use JQ syntax to parse values, see the [JQ documentation][jq_documentation].
+
+## External Commands
+
+External Commands are used to wrap 3rd party applications. RBCli accomplishes this by allowing you to set environment variables and command line parameters based on your input variables.
+
+RBCli provides this feature through the `extern` keyword. It provides two modes -- __direct path__ and __variable path__ -- which work similarly.
+
+
+### Direct Path Mode
+
+Direct path mode is the simpler mode of the two External Command modes. It allows you to provide a specific command with environment variables set, though it does not allow using RBCli parameters, arguments, options, and config.
+
+ ```ruby
+class List < Rbcli::Command
+ 	extern path: 'path/to/application', envvars: {MYVAR: 'some_value'}                               # (Required) Runs a given application, with optional environment variables, when the user runs the command.
+end
+ ```
+
+Here, we supply a string to run the command. We can optioanlly provide environment variables which will be set for the external application.
+
+### Variable Path Mode
+
+Variable Path mode works the same as Direct Path Mode, only instead of providing a string we provide a block that returns a string (which will be the command executed). This allows us to generate different commands based on the CLI parameters that the user passed, or pass configuration as CLI parameters to the external application:
+
+```ruby
+class Test < Rbcli::Command
+	extern envvars: {MY_OTHER_VAR: 'another_value'} do |params, args, global_opts, config|          # Alternate usage. Supplying a block instead of a path allows us to modify the command based on the arguments and configuration supplied by the user. This allows passing config settings as command line arguments to external applications. The block must return a string, which is the command to be executed.
+		cmd = '/path/to/application'
+		cmd += ' --test-script foo --ignore-errors' if params[:force]
+		cmd
+	end
+end
+```
+
+__NOTE__: Passing user-supplied data as part of the command string may be a security risk (example: `/path/to/application --name #{params[:name]}`). It is highly recommended to provide the fixed strings yourself, and only select which strings are used based on the variables provided. This is demonstrated in the example above.
+
+
+[your_first_command]: ../tutorial/30-your_first_command.md
+[parameters_documentation]: ../tutorial/40-options_parameters_and_arguments.md
+[user_config_documentation]: ../advanced/user_config_files.md
+[jq_documentation]: https://stedolan.github.io/jq/manual/

data/docs-src/docs/advanced/distributed_state_locking.md

@@ -0,0 +1,33 @@
+# Distributed Locking and State Sharing
+
+Distributed Locking allows a [Remote State][state_storage] to be shared among multiple users of the application to make writes appear atomic between sessions. To use it, simply set the  `locking:` parameter to `true` when enabling remote state.
+
+This is how locking works:
+
+1. The application attempts to acquire a lock on the remote state when you first access it
+2. If the backend is locked by a different application, wait and try again
+3. If it succeeds, the lock is held and refreshed periodically
+4. When the application exits, the lock is released
+5. If the application does not refresh its lock, or fails to release it when it exits, the lock will automatically expire within 60 seconds
+6. If another application steals the lock (unlikely but possible), and the application tries to save data, a `StandardError` will be thrown
+7. You can manually attempt to lock/unlock by calling `Rbcli.remote_state.lock` or `Rbcli.remote_state.unlock`, respectively. 
+
+
+## Manual Locking
+
+Remember: all state in Rbcli is lazy-loaded. Therefore, RBCli wll only attempt to lock the data when you first try to access it. If you need to make sure that the data is locked before executing a block of code, use:
+
+```ruby
+Rbcli.remote_state.refresh
+```
+
+to force the lock and retrieve the latest data. You can force an unlock by calling:
+
+```ruby
+Rbcli.remote_state.disconnect
+```
+
+Even if you do not want to store any data, you can leverage manual locking to control access to a different shared resource, such as a stateful API. For example, if you write a cloud deployment toolkit, you can ensure that only one user is attempting to modify a deployment at any given time.
+
+
+[state_storage]: state_storage.md

data/docs-src/docs/advanced/hooks.md

@@ -0,0 +1,65 @@
+# Execution Hooks
+
+RBCli provides you with hooks that can be used to have code execute at certain places in the execution chain. These hooks are optional, and do not have to be defined for your application to run.
+
+All hooks will be created in the `hooks/` folder in your project.
+
+## The Defailt Action Hook
+
+The Default hook is called when a user calls your application without providing a command. If the hook is not provided, the application will automatically display the help text (the same as running it with `-h`).
+
+To create it in your project, run:
+
+```bash
+rbcli hook --default
+# or
+rbcli hook -d
+```
+
+You will then find the hook under `hooks/default_action.rb`.
+
+
+## The Pre-Execution Hook
+
+The Pre-Execution hook is called after the global command line options are parsed and before a command is executed.
+
+To create it in your project, run:
+
+```bash
+rbcli hook --pre
+# or
+rbcli hook -p
+```
+
+You will then find the hook under `hooks/pre_execution.rb`.
+
+## The Post-Execution Hook
+
+The Pre-Execution hook is called after a command is executed.
+
+To create it in your project, run:
+
+```bash
+rbcli hook --post
+# or
+rbcli hook -o
+```
+
+You will then find the hook under `hooks/post_execution.rb`.
+
+## The First-Run Hook
+
+The First-Run hook is called the first time a user executes your application. Using the first-run hook requires enabling [Local State Storage][state_storage] for persistence.
+
+To create it in your project, run:
+
+```bash
+rbcli hook --firstrun
+# or
+rbcli hook -f
+```
+
+You will then find the hook under `hooks/first_run.rb`.
+
+
+[state_storage]: state_storage.md

data/docs-src/docs/advanced/logging.md

@@ -0,0 +1,35 @@
+# Logging
+
+Logging with RBCli is straightforward - it looks at the config file for logging settings, and instantiates a single, globally accessible [Logger][ruby_logger] object. You can access it within a standard command like this:
+
+```ruby
+Rbcli::log.info { 'These logs can go to STDERR, STDOUT, or a file' }
+```
+
+## Enabling Logging
+
+To enable logging, simply set the default values in the `config/logging.rb` file:
+
+```ruby
+log_level :info
+log_target 'stderr'
+```
+
+* `log_level`
+	* You can set the default log level using either numeric or standard Ruby logger levels: 0-5, or DEBUG < INFO < WARN < ERROR < FATAL < UNKNOWN
+* `log_target`
+	* This specifies where the logs will be placed. Valid values are nil (disables logging), 'STDOUT', 'STDERR', or a file path (all as strings).
+
+## Userspace Config Overrides
+
+If [Userspace Configuration][userspace_configuration] is enabled, these options will also be present in the user's config file to override defaults: 
+
+```yaml
+# Log Settings
+logger:
+  log_level: warn              # 0-5, or DEBUG < INFO < WARN < ERROR < FATAL < UNKNOWN
+  log_target: stderr           # STDOUT, STDERR, or a file path
+```
+
+[ruby_logger]: https://ruby-doc.org/stdlib-2.4.0/libdoc/logger/rdoc/Logger.html
+[userspace_configuration]: user_config_files.md

data/docs-src/docs/advanced/state_storage.md

@@ -0,0 +1,117 @@
+# State Storage
+
+RBCli supports both local and remote state storage. This is done by synchronizing a Hash with either the local disk or a remote database.
+
+## Local State
+
+RBCli's local state storage gives you access to a hash that is automatically persisted to disk when changes are made.
+
+### Configuration
+
+You can configure it in `config/storage.rb`.
+
+```ruby
+local_state '/var/mytool/localstate', force_creation: true, halt_on_error: true
+```
+
+There are three parameters to configure it with:
+
+* The `path` as a string (self-explanatory)
+* `force_creation`
+	* This will attempt to create the path and file if it does not exist (equivalent to an `mkdir -p` and `touch` in linux)
+* `halt_on_error`
+	* RBCli's default behavior is to raise an exception if the file can not be created, read, or updated at any point in time
+	* If this is set to `false`, RBCli will silence any errors pertaining to file access and will fall back to whatever data is available. Note that if this is enabled, changes made to the state may not be persisted to disk.
+		* If creation fails and file does not exist, you start with an empty hash
+		* If file exists but can't be read, you will have an empty hash
+		* If file can be read but not written, the hash will be populated with the data. Writes will be stored in memory while the application is running, but will not be persisted to disk.
+
+
+### Access and Usage
+
+Once configured you can access it with a standard hash syntax in your Standard Commands:
+
+```ruby
+Rbcli.local_state[:yourkeyhere]
+```
+
+The methods available for use at the top level are as follows:
+
+Hash native methods:
+
+* `[]` (Regular hash syntax. Keys are accessed via either symbols or strings indifferently.)
+* `[]=` (Assignment operator)
+* `delete`
+* `each`
+* `key?`
+
+Additional methods:
+
+* `commit`
+	* Every assignment to the top level of the hash will result in a write to disk (for example: `Rbcli.local_state[:yourkey] = 'foo'`). However, if you are manipulating nested hashes, these saves will not be triggered. You can trigger them manually by calling `commit`.
+* `clear`
+	* Resets the data back to an empty hash.
+* `refresh`
+	* Loads the most current version of the data from the disk
+* `disconnect`
+	* Removes the data from memory and sets `Rbcli.local_state = nil`. Data will be read from disk again on next access.
+
+
+Every assignment will result in a write to disk, so if an operation will require a large number of assignments/writes it should be performed to a different hash before beign assigned to this one.
+
+
+## Remote State
+
+RBCli's remote state storage gives you access to a hash that is automatically persisted to a remote storage location when changes are made. It has optional locking built-in, meaning that multiple users may share remote state without any data consistency issues.
+
+Currently, this feature requires AWS DynamoDB, though other backend systems will be added in the future.
+
+### Configuration
+
+Before DynamoDB can be used, AWS API credentials have to be created and made available. RBCli will attempt to find credentials from the following locations in order:
+
+1. User's config file
+2. Environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`
+3. User's AWSCLI configuration at `~/.aws/credentials`
+
+For more information about generating and storing AWS credentials, see [Configuring the AWS SDK for Ruby][aws_sdk_credentials]. Please make sure that your users are aware that they will need to provide their own credentials to use this feature.
+
+You can configure it in `config/storage.rb`.
+
+```ruby
+remote_state_dynamodb table_name: 'mytable', region: 'us-east-1', force_creation: true, halt_on_error: true, locking: false
+```
+
+These are the parameters:
+
+* `table_name`
+	* The name of the DynamoDB table to use.
+* `region`
+	* The AWS region that the database is located
+* `force_creation`
+	* Creates the DynamoDB table if it does not already exist
+* `halt_on_error`
+	* Similar to the way [Local State](#local-state) works, setting this to `false` will silence any errors in connecting to the DynamoDB table. Instead, your application will simply have access to an empty hash that does not get persisted anywhere.
+	* This is good for use cases that involve using this storage as a cache, where a connection error might mean the feature doesn't work but its not important enough to interrupt the user.
+* `locking`
+	* Setting this to `true` enables locking, meaning only one instance of your application can access the shared data at any given time. For more information see [Distributed State Locking][distributed_state_locking].
+
+
+### Access and Usage
+
+Once configured you can access it with a standard hash syntax:
+
+```ruby
+Rbcli.remote_state[:yourkeyhere]
+```
+
+This works the same way that [Local State](#local-state) does, with the same performance caveats (try not to write too frequently).
+
+Note that all state in Rbcli is __lazy-loaded__, so no connections will be made until your code attempts to access the data even if the feature is enabled.
+
+For more information on the available commands, see the documentation on [Local State](#local-state)
+
+
+[aws_sdk_credentials]: https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/setup-config.html
+[distributed_state_locking]: distributed_state_locking.md
+

data/docs-src/docs/advanced/user_config_files.md

@@ -0,0 +1,47 @@
+# Configuration Files
+
+RBCli provides built-in support for creating and managing userspace configuration files. It does this through two chains: the __defaults chain__ and the __user chain__.
+
+## Defaults chain
+
+The defaults chain allows you to specify sane defaults for your CLI tool throughout your code. This gives you the ability to declare configuration alongside the code, and allows RBCli to generate a user config automatically given your defaults. There are two ways to set them:
+
+* YAML Files
+	* You can store your defaults in one or more YAML files and RBCli will import and combine them. Note that when generating the user config, RBCli will use the YAML text as-is, so comments are transferred as well. This allows you to write descriptions for the options directly in the file that the user can see.
+	* This is good for tools with large or complex configuration that needs user documentation written inline
+	* These YAML files should be placed in the `userconf/` directory in your project and they will automatically be loaded
+* DSL Statements
+	* In the DSL, you can specify options individually by providing a name, description, and default value
+	* This is good for simpler configuration, as the descriptions provided are written out as comments in the generated user config
+	* You can put global configuration options in `config/userspace.rb`
+	* Command-specific confiugration can be placed in the command declarations in `application/commands/*.rb`
+
+DSL statements appear in both of the above locations as the following:
+
+```ruby
+config_default :name, description: '<description_help_text>', default: '<default_value>'
+```
+## User chain
+
+The user chain has two functions: generating and loading configuration from a YAML file on the end user's machine.
+
+Rbcli will determine the correct location to locate the user configuration based on two factors:
+
+1. The default location set in `config/userspace.rb`
+2. The location specified on the command line using the `--config-file=<filename>` option (overrides #1)
+
+To configure the default location, edit `config/userspace.rb`:
+
+```ruby
+config_userfile '~/.mytool', merge_defaults: true, required: false
+```
+
+* `path/to/config/file`
+	* Self explanatory. Recommended locations are a dotfile in the user's home directory, or a file under `/etc` such as `/etc/mytool/userconf.yaml`
+* `merge_defaults`
+	* If set to `true`, user settings override default settings. If set to `false`, default settings are not loaded at all and the user is required to have all values specified in their config.
+* `required`
+	* If set to `true` the application will not run if the file does not exist. A message will be displayed to the user to run your application with the `--generate-config` option to generate the file given your specified defaults.
+
+
+Users can generate configs by running `yourclitool --generate-config`. This will generate a config file at the tool's default location specified in the DSL. This location can be overridden via the `--config-file=<filename>` option.

data/docs-src/docs/development/code_of_conduct.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at andrew@blacknex.us. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

data/docs-src/docs/development/contributing.md

@@ -0,0 +1,49 @@
+# Contribution Guide
+
+Contributing to RBCli is the same as most open source projects:
+
+1. Fork the repository
+2. Create your own branch
+3. Submit a pull request when ready
+
+That's all there is to it! We've also kept our acceptance criteria pretty simple, as you'll see below. Feel free to submit a pull request even if you don't meet it if you would like your code or feature to be reviewed first; we do want to be mindful of your time and will review submissions before they are polished.
+
+# Code Acceptance Criteria
+
+## Tabs, Not Spaces
+
+Please, and thanks. We all like to use different indentation levels and styles, and this will keep us consistent between editors.
+
+For filetypes where tabs are not supported (such as YAML), please stick to using two (2) spaces.
+
+## Documentation for User Features
+
+For any modification that alters the way RBCli is used -- we're talking additional features, options, keyword changes, major behavioral changes, and the like -- the documentation will need to be updated as well. You'll be happy to know we designed it to make the process relatively painless.
+
+RBCli's documentation is essentially a collection of markdown files that have been compiled into a static site using [MkDocs](https://www.mkdocs.org). If you already have python and pip on your system, you can install it by running:
+
+```bash
+pip install mkdocs mkdocs-material
+```
+
+You can find the source markdown files in the `docs-src/docs` folder, and the menu organization in `docs-src/mkdocs.yml`. To preview your changes on a live site, run:
+
+```bash
+mkdocs serve
+```
+
+Also, don't forget to update the __Quick Reference Guide__ in the `README.md` file (the main project one) with information about your changes.
+
+Once you've completed your edits, run the `makesite.sh` command to build the actual HTML pages automatically in the `docs` folder, from where they will be served when live.
+
+# Maintainer's Notes
+
+To install this gem onto your local machine from source, run `bundle exec rake install`.
+
+To release a new version, follow theese steps:
+
+1. Update the version number in `version.rb`
+2. Run `bundle exec rake install`, which will update `gemfile.lock` with the correct version and all dependency changes
+3. Run `docs-src/makesite.sh`, which re-compiles the documentation and pulls in the changelog and quick reference automatically
+4. Commit the above changes to master, but do not push
+5. Run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).

data/docs-src/docs/development/license.md

@@ -0,0 +1,10 @@
+# How RBCli is Licensed
+
+We want to help the developer community build tooling faster and with less work. That's why RBCli was built. And let's face it - most of us aren't lawyers, and don't want to worry about legal fine print when building awesome software. That's why RBCli is released under the __GPLv3 License__. So you're free to use RBCli as you see fit to write free software. If you wish to use RBCli in a commercial offering, please contact me at [andrew@blacknex.us](mailto:andrew@blacknex.us).
+
+
+# The License
+
+You can view the offical license for RBCli [Here](https://github.com/akhoury6/rbcli/blob/master/LICENSE.txt).
+
+For more details about the GPLv3 License, see [Here](https://choosealicense.com/licenses/gplv3/).

data/docs-src/docs/imported/changelog.md

@@ -0,0 +1,31 @@
+# Changelog
+
+## 0.2.0 (Aug 5, 2018)
+
+### Features
+
+* Official documentation created and hosted with Github Pages
+* RBCli released under GPLv3
+* Copyright/License notice displayed via RBCli tool with `rbcli license` in accordance with GPLv3 guidelines
+
+### Bugfixes
+
+* Fixed version number loading for projects
+* Cleaned up command usage help output
+* Fixed script and external command generation
+
+### Improvements
+
+* A quick reference guide can now be found in README.md
+* CLI tool Autoupdate Enabled; when an upgrade to RBCli is detected, the RBCli CLI tool will notify the developer.
+* Autoupdate feature now allows supplying a custom message
+* Direct Path Mode for External Commands now
+* Added support for a `lib` folder in projects, as a place for custom code, which is automatically added to `$LOAD_PATH` for developers
+* Improved language regarding external commands: Documentation now differentiates between Standard, Scripted, and External Commands
+* Improved language regarding user config files: Now called Userspace Config
+* Options and Parameters now allow specifying the letter to be used for the short version, or to disable it altogether
+* Userspace config can now be disabled by setting the path to nil or removing the declaration
+
+### Deprecations/Changes
+
+* Removed deprecated and broken examples from the examples folder