I manage a “DigitalOcean Droplet” to host a website for a nonprofit. We have a private repo on GitHub for source control. Since we built it, we had to manually deploy each time, even for simple tasks like publishing a new article. As GitHub offers Actions to automate deployment, naturally we want to benefit from that.

Goal

In short, we need to write a config file, in YAML, so that when we push new code to GitHub, GitHub can read the config file, orchestrate the DigitalOcean droplet based on the config, so that the site can be rebuilt, redeployed(via a few Docker commands) on the DO droplet.

My hunch was, there should be easily an existing solution working perfectly fine, what I needed to do was discover it(likely on GitHub) and use it.

The failed attempt

With some quick Googling, it seems that DigitalOcean has some official recommended way to talk to DigitalOcean via GitHub Actions: GitHub Actions for DigitalOcean. This looks promising: I could find bunch of examples using this. It requirs me to create a personal token to invoke their public APIs, so I did. From a glance at the documentations I found APIs for “Droplets” and “Droplet Actions”. I first played around some APIs locally to simply query my account info, invoice. They worked perfectly as I expected, so far so good.

As I kept going, I realized a gap: “Droplet” is the most basic feature of Digital Ocean, costs $5 a month. The public APIs around droplet are about querying/creating/updating/deleting droplet. The example action I could find also assumes I use Digital Ocean’s Kubernetes feature and the “early availability” Container Registry feature, both costs extra money. Is it the only aviable way to do so?

The solution

Took a step back and looked again at the commands I had to run on the Droplet: pretty straightforward and simple:

ssh to the droplet
git pull # from our repo
docker build # and other docker commands

So, what I really need to is to simulate that. Digging more, I found a project called SSH-Action for Github to execute remote SSH commands in Actions. I gave it a try, with help from GitHub Secrets:

      - name: Pull from GitHub
        uses: appleboy/ssh-action@master
        with:
          host: $
          username: $
          password: $
          script: cd ~/path/to/project && git pull git@github.com:project/home.git

Then the other steps got super easy: just define more Workflow steps, invoke multiple commands via SSH, to run the docker commands. Putting them together, I got a straightforward workflow running like this(just as example, won’t work if just copy-pasting).

Takeaway

No, I didn’t discover an existing solution perfectly fit my requirement. But yes, it was easy to leverage a few building blocks, to build a solution simple enough to perfectly fulfill my own requirement.

There was also serendipity. While testing all this, I found a handy tool called act by Casey Lee. It enabled me to test GitHub Actions locally, rather than test in production.