Proof-of-Concept Serverless Daemon about inertia

[jordanschalm]

I prefer Option 2 even if the port opening has to be done manually. For a few reasons:

• Even if we're constantly polling GitHub, we'll always be waiting longer for deployments to happen.
• I suspect the polling design would respond less gracefully to "weird" events without the context of a webhook payload (renaming the repo, force pushing to roll back, etc.)
• Omitting the port opening issue, I think we can all agree using webhooks is a better, more elegant design than polling (if we can't, lmk 😅). And I don't think it's worth it to use a worse design for the whole system in order to save one step during setup.

[jordanschalm]

We're considering two high-level designs for the daemon:

1. Polling Daemon - Get the deployable resource every N mins, if it is different from our current version, pull+deploy it.
2. Server Daemon - Listens for incoming webhooks POSTs, checks that the branch is the deploy branch, if so, pull+deploy it.

If we're going to prototype these two designs, we should come up with some properties we want to compare between the two, so we know how to decide once the prototypes are built 😀. But I think unless we're going to measure CPU/network usage between the two (probably pretty similar and negligible), we can decide between the two without prototyping them.

[chadlagore]

I agree. I'll reiterate the port opening property, if that can some how be automated away I'd prefer design 2 (I don't see how it can, as you say very provider specific). Thats my central hangup on 2.

[bobheadxi]

Yeah I don't think having to manually open a port is too much of a price to pay for a cleaner overall design

[chadlagore]

Even if we're constantly polling GitHub, we'll always be waiting longer for deployments to happen.

Agreed.

I suspect the polling design would respond less gracefully to "weird" events without the context of a webhook payload (renaming the repo, force pushing to roll back, etc.)

Mayyyyybe.

Omitting the port opening issue, I think we can all agree using webhooks is a better, more elegant design than polling

I agree, and after some digging, it seems that this is how AWS CodeDeploy and other CD services integrate with github - as expected - but they have the benefit of being able to control port access on their end.

The port is a price we have to pay for not owning our own cloud datacenter. Now whose fault is that? (glares at @bfbachmann)

👍 on server daemon.