From 031a193c1e99d82e2127168c4925727f7adf63e5 Mon Sep 17 00:00:00 2001 From: Chris Caron Date: Tue, 5 Mar 2019 21:36:51 -0500 Subject: [PATCH] Created config_yaml (markdown) --- config_yaml.md | 110 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) create mode 100644 config_yaml.md diff --git a/config_yaml.md b/config_yaml.md new file mode 100644 index 0000000..b60b736 --- /dev/null +++ b/config_yaml.md @@ -0,0 +1,110 @@ +## YAML Based Configuration Files +YAML Support added now which is slightly different then how it was identified at the start of this thread (so ignore that and role with this instead). Here is the configuration in it's absolute simplest form: +```yaml +# +# Minimal Configuration Example +# + +# Define your URLs +urls: + # Either on-line each entry like this: + - json://localhost + - xml://localhost + + # Or add a colon to the end of the URL where you can optionally provide + # over-ride entries. One of the most likely entry to be used here + # is the tag entry. This gets extended to the global tag (if defined) + # above + - windows://: + # 'tag' is a special keyword that allows you to associate tags with your + # services: + - tag: desktop +``` + +To expand on **tags**, you can also identify a _global entry_ that will be applied _to ALL of the subsequent URL entries defined in the YAML file_. Example +```yaml +# +# Global Tag Configuration Example +# + +# Define our version +version: 1 + +# Our global tags to associate with all of the URLs we define +tag: admin, devops + +# Define your URLs (Mandatory!) +urls: + - xml://localhost + - json://localhost + - kodi://user:pass@myserver +``` + +You can over-ride the AppriseAsset Object too if you know the objects you want to update using the special keyword **asset**. +```yaml +# +# Asset Override Configuration Example +# + +# Define our version +version: 1 + +# Define an Asset object if you wish (Optional) +asset: + app_id: NuxRef + app_desc: NuxRef Notification + app_url: http://nuxref.com + +# Define your URLs (Mandatory!) +urls: + - mailto://bill:pass@protomail.com +``` + +YAML configuration gets more powerful when you want to utilize a URL more then once. Here is a more complicated example: +```yaml +# if no version is specified then version 1 is presumed. Thus this is a +# completely optional field. It's a good idea to just add this line because it +# will help with future ambiguity (if it ever occurs). +version: 1 + +# Define an Asset object if you wish (Optional) +asset: + app_id: AppriseTest + app_desc: Apprise Test Notifications + app_url: http://nuxref.com + +# Optionally define some global tags to associate with ALL of your +# urls below. +tag: admin, devops + +# Define your URLs (Mandatory!) +urls: + # One-liner (no colon at the end); just the url as you'd expect it: + - json://localhost + + # A colon grants you customization; the below associates a tag + - xml://localhost: + - tag: customer + + # Replication Example # + # The more elements you specify under a URL the more times the URL will + # get replicated and used. Hence this entry actually could be considered + # 2 URLs being called with just the destination email address changed: + - mailto://george:password@gmail.com: + - to: jason@hotmail.com + - to: fred@live.com + + # Again... to re-iterate, the above mailto:// would actually fire two (2) + # separate emails each with a different destination address specified. + # Be careful when defining your arguments and differentiating between + # when to use the dash (-) and when not to. Each time you do, you will + # cause another instance to be created. + + # Defining more then 1 element to a muti-set is easy, it looks like this: + - mailto://jackson:abc123@hotmail.com: + - to: jeff@gmail.com + tag: jeff, customer + + - to: chris@yahoo.com + tag: chris, customer +```