Definitions

• Client-side: CLI calls made via inertia binary, run from inside your repo locally, some of which make HTTP requests to the server, some of which pipe commands over SSH to bootstrap the server.
• Server-side: Daemon activity (receiving HTTP requests and responding appropriately) and bootstrapping activity (running scripts piped over SSH) on the server.

Background

The daemon runs on the server after we call:

▶ inertia remote bootstrap [REMOTE]

Then we can make sure its running with:

▶ inertia remote status [REMOTE]
# Remote instance '[REMOTE]' accepting requests at http://35.227.171.49:8081

• The daemon is simply a web server running in a docker container with access to the docker socket via this trick.
• The daemon was started when the client CLI tool ran this script over SSH (one of the steps in the implementation of the bootstrap call).
• The daemon accepts generic hooks from GitHub on /. It currently logs the information it receives and nothing more.
• The server provided the client with a public deploy key (after the bootstrap call) and asked the user to associate the key with their GitHub repository (effectively giving the daemon readonly access to the repository).
• The daemon currently has two other endpoints.

1. /up [POST] Bring the project up. This could fail for a myriad of reasons.
   • Upon receiving a POST to this endpoint, the project could not yet be cloned (cloning functionality laid out in the POC). We have to try to clone it, this could fail due to the user not yet giving the daemon readonly access (failing to have added the deploy key), return an appropriate error.
   • The project may already be cloned, conventionally we may either disregard the POST or force re-deploy the project with a git pull, docker-compose up; I'm partial to the latter, but maybe a client-side flag is in order.
   • The user may not have added the URL for webhooks. I'm not sure if this something the daemon can learn by querying the GitHub API, but it would be helpful user feedback - perhaps this falls into the "nice to have" category.
2. /down [POST] Bring the project down. Fail in the situation where no other containers besides the daemon itself are running. Use the docker POC to learn this.

Finally, the daemon needs some sort of authorization. A token needs to be transferred to the client on bootstrap - something to think about how to do.