Configuration about inertia

[jordanschalm]

RE Configuration Options:

• I don't understand why we would need to specify URLs to receive webhooks (?)
• Domains to accept webhooks should be handled by checking the secret we share with GitHub (when the webhook is created)
• PR and push request will probably be the same event (push to a particular branch) for our purposes. Unless we only want to deploy only when a PR is merged, but not for any push to master (for any sensible setup these will be the same though 🤔)
• I don't think the secret should be a configuration option per se. We should generate it for the user on initialization (there's no reason to make someone generate a random string on their own 😛) and store it to use to check incoming webhooks

RE Configuration Methods:
Why can't the YML just be a part of the repo we're building? Inertia doesn't know exactly how to deploy your repo until it gets the first webhook. If you want to change your deployment strategy, merge a PR with a modified inertia.yml 😀.

I don't agree that we should aim to build in remote interaction. The difference we're looking at is:
With building RPC into Inertia:

inertia <cmd>

Without building RPC into Inertia:

ssh root@box
inertia <cmd>

But with option 1 we need to either use SSH under the hood anyway or implement addressing, transport security, authentication, etc. I don't think our goal should be to avoid requiring ssh. Instead I think our goal should be to do as little as possible while in ssh.

I think having builtin RPC is a nice-to-have neato feature, but I think the costs FAR outweigh the benfits.

[bobheadxi]

Closing since discussion has moved to more specific tickets (ie #67)