picobot > pico

Author: Southclaws

README.md

@@ -1,18 +1,18 @@
-# Picobot
+# Pico
 
 _The little git robot of automation!_
 
-[![Build Status](https://travis-ci.org/picostack/picobot.svg?branch=master)](https://travis-ci.org/picostack/picobot)
+[![Build Status](https://travis-ci.org/picostack/pico.svg?branch=master)](https://travis-ci.org/picostack/pico)
 
-Picobot is a git-driven task runner to automate the application of configs.
+Pico is a git-driven task runner to automate the application of configs.
 
 ## Overview
 
-Picobot is a little tool for implementing [Git-Ops][git-ops] in single-server environments. It's analogous to
+Pico is a little tool for implementing [Git-Ops][git-ops] in single-server environments. It's analogous to
 [kube-applier][kube-applier], [Terraform][terraform], [Ansible][ansible] but for automating lone servers that do not
 need cluster-level orchestration.
 
-Instead, Picobot aims to be extremely simple. You give it some Git repositories and tell it to run commands when those
+Instead, Pico aims to be extremely simple. You give it some Git repositories and tell it to run commands when those
 Git repositories receive commits and that's about it. It also provides a way of safely passing in credentials from
 [Hashicorp's Vault][vault].
 
@@ -21,16 +21,16 @@ Git repositories receive commits and that's about it. It also provides a way of
 ### Linux
 
 ```sh
-curl -s https://raw.githubusercontent.com/picostack/picobot/master/install.sh | bash
+curl -s https://raw.githubusercontent.com/picostack/pico/master/install.sh | bash
 ```
 
 Or via Docker:
 
 ```sh
-docker pull picostack/picobot:v1
+docker pull picostack/pico:v1
 ```
 
-See the docker section below and the image on [Docker Hub](https://hub.docker.com/r/picostack/picobot).
+See the docker section below and the image on [Docker Hub](https://hub.docker.com/r/picostack/pico).
 
 ### Everything Else
 
@@ -39,22 +39,22 @@ Windows/Mac usage is probably just local testing so just use `go get` for these
 
 ## Usage
 
-Currently, Picobot has a single command: `run` and it takes a single parameter: a Git URL. This Git URL defines the
-"Config Repo" which contains Picobot configuration files. These configuration files declare where Picobot can find
-"Target Repos" which are the repos that contain all the stuff you want to automate. The reason Picobot is designed
-this way instead of just using the target repos to define what Picobot should do is 1. to consolidate Picobot config
+Currently, Pico has a single command: `run` and it takes a single parameter: a Git URL. This Git URL defines the
+"Config Repo" which contains Pico configuration files. These configuration files declare where Pico can find
+"Target Repos" which are the repos that contain all the stuff you want to automate. The reason Pico is designed
+this way instead of just using the target repos to define what Pico should do is 1. to consolidate Pico config
 into one place, 2. separate the config of the tools from the applications and 3. keep your target repos clean.
 
-Picobot also has a Docker image - see below for docker-specific information.
+Pico also has a Docker image - see below for docker-specific information.
 
 ### Configuration
 
-The precursor to Picobot used JSON for configuration, this was fine for simple tasks but the ability to provide a
+The precursor to Pico used JSON for configuration, this was fine for simple tasks but the ability to provide a
 little bit of logic and variables for repetitive configurations is very helpful. Inspired by [StackExchange's
-dnscontrol][dnscontrol], Picobot uses JavaScript files as configuration. This provides a JSON-like environment with
+dnscontrol][dnscontrol], Pico uses JavaScript files as configuration. This provides a JSON-like environment with
 the added benefit of conditional logic.
 
-Here's a simple example of a configuration that should exist in the Picobot config repo that re-deploys a Docker
+Here's a simple example of a configuration that should exist in the Pico config repo that re-deploys a Docker
 Compose stack whenever it changes:
 
 ```js
@@ -71,7 +71,7 @@ T({
 
 The `T` function declares a "Target" which is essentially a Git repository. In this example, the repository
 `[email protected]:username/my-docker-compose-project` would contain a `docker-compose.yml` file for some application
-stack. Every time you make a change to this file and push it, Picobot will pull the new version and run the command
+stack. Every time you make a change to this file and push it, Pico will pull the new version and run the command
 defined in the `up` attribute of the target, which is `docker-compose up -d`.
 
 You can put as many target declarations as you want in the config file, and as many config files as you want in the
@@ -133,23 +133,23 @@ have a bunch of compose configs that all mount data to some path on the machine,
 
 See the `docker-compose.yml` file for an example and read below for details.
 
-You can run Picobot as a Docker container. If you're using it to deploy Docker containers via compose, this makes the
-most sense. This is quite simple and is best done by writing a Docker Compose configuration for Picobot in order to
+You can run Pico as a Docker container. If you're using it to deploy Docker containers via compose, this makes the
+most sense. This is quite simple and is best done by writing a Docker Compose configuration for Pico in order to
 bootstrap your deployment.
 
-The Picobot image is built on the `docker/compose` image, since most use-cases will use Docker or Compose to deploy
+The Pico image is built on the `docker/compose` image, since most use-cases will use Docker or Compose to deploy
 services. This means you must mount the Docker API socket into the container, just like Portainer or cAdvisor or any of
 the other Docker tools that also run inside a container.
 
 The socket is located by default at `/var/run/docker.sock` and the `docker/compose` image expects this path too, so you
 just need to add a volume mount to your compose that specifies `/var/run/docker.sock:/var/run/docker.sock`.
 
-Another minor detail you should know is that Picobot exposes a `HOSTNAME` variable for the configuration script.
+Another minor detail you should know is that Pico exposes a `HOSTNAME` variable for the configuration script.
 However, when in a container, this hostname is a randomised string such as `b50fa67783ad`. This means, if your
-configuration performs checks such as `if (HOSTNAME === 'server031')`, this won't work. To resolve this, Picobot will
+configuration performs checks such as `if (HOSTNAME === 'server031')`, this won't work. To resolve this, Pico will
 attempt to read the environment variable `HOSTNAME` and use that instead of using `/etc/hostname`.
 
-This means, you can bootstrap a Picobot deployment with only two variables:
+This means, you can bootstrap a Pico deployment with only two variables:
 
 ```env
 VAULT_TOKEN=abcxyz
@@ -158,7 +158,7 @@ HOSTNAME=server012
 
 ### Docker Compose and `./` in Container Volume Mounts
 
-Another caveat to running Picobot in a container to execute `docker-compose` is the container filesystem will not
+Another caveat to running Pico in a container to execute `docker-compose` is the container filesystem will not
 match the host filesystem paths.
 
 If you mount directories from your repository - a common strategy for versioning configuration - `./` will be expanded