Deploy to Flywheel via SSH and GitHub Actions

Create the YAML config file

Open up your favorite code editor and create an empty .github/ directory at the root of your project (typically your custom theme or plugin). Inside of that newly created directory, create another empty workflows/ directory. Finally, inside of workflows/ directory, create a file called main.yml. The name of the YAML file really doesn’t matter as GitHub will simply look for a YAML file, but we’ll use main.yml for our example.

Fill out the YAML config file

The YAML config file must follow a certain syntax for GitHub to read it correctly. For our workflow, we just need name, on, and jobs top-level keys. Here’s the full workflow that you can copy and paste! We’ll break it down below.

[code lang=”yaml”]
name: Flywheel SSH Deploy
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v2
– name: Deploy to Server
uses: easingthemes/[email protected]
env:
SSH_PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }}
REMOTE_HOST: ssh.getflywheel.com
REMOTE_USER: ${{ secrets.SSH_USER }}
ARGS: -rltgoDzvO –exclude .git –exclude .github
TARGET: /www/wp-content/themes/
[/code]

• name:
  This is the name of the workflow that will show up in GitHub. You can use whatever name you’d like!
• on:
  This tells GitHub Actions when to run the steps listed in jobs:. A full list of available values for this key can be found here, but we’ll stick to triggering the workflow when someone pushes to the branch named main.
• jobs.build:
  This is the bulk of the workflow. Workflows can contain one or more jobs, but for our example, we just need one job and we’re calling it build (the name of the job doesn’t matter to the workflow– it can be whatever you want, but we recommend something semantic).
• jobs.build.runs-on:
  This tells GitHub Actions to run our job on a machine with the latest Ubuntu installed.
• jobs.build.steps:
  Here are the steps that GitHub Actions will follow on the Ubuntu machine.
• At this point in our example, we’re following the recommended configuration of the easingthemes/ssh-deploy Action. It’s a GitHub Action built by a third party that we’re basically extending and using as our base for our own custom Action. The keys here define a name (that can be whatever you want), which version of the easingthemes/ssh-deploy Action to use, and then the unique information for your Flywheel server that’s needed to know where to push the code to.
• jobs.build.steps.env.SSH_PRIVATE_KEY:
  This is your private SSH key. You’ll want to store it in your GitHub repo’s encrypted secrets. More information on adding your private key is listed below.
• jobs.build.steps.env.REMOTE_HOST:
  This should be your remote host’s SSH address, which for all Flywheel sites is ssh.getflywheel.com.
• jobs.build.steps.env.REMOTE_USER:
  This is the user used to authenticate to ssh.getflywheel.com. More information is listed below, but it should follow this syntax: your-flywheel-username+site-slug.
• jobs.build.steps.env.ARGS:
  This is to exclude unnecessary directories so they aren’t deployed to the Flywheel site.
• jobs.build.steps.env.TARGET:
  This is where GitHub Actions will deploy the code to.

Enter the SSH_PRIVATE_KEY and REMOTE_HOST encrypted secrets into GitHub Secrets

As mentioned above, there are two variables that should be stored in the GitHub’s Secrets tab of your repository so that you’re not hard-coding confidential information into your repo.

To add these secrets, head over to your GitHub repo and select the “Settings” tab on the far right, then select “Secrets” towards the bottom of the left side navigation.

PRIVATE_KEY
Add a new secret and name it SSH_PRIVATE_KEY. In the value field, you’ll want to paste the PEM format of your private SSH key. This must be the private key from the private/public key pair that you use for Flywheel SSH and must be in PEM format to work with the easingthemes/ssh-deploy Action. To convert the private key to PEM format, use this command, replacing id_rsa with your private key name if the file name is different:

openssl rsa -in ~/.ssh/id_rsa -outform pem

If you would like to automatically copy the output of that command to your clipboard, pipe the command to the appropriate platform-specific command like so:

macOS: openssl rsa -in ~/.ssh/id_rsa -outform pem | pbcopy

Windows: openssl rsa -in ~/.ssh/id_rsa -outform pem | clip

More information on generating public and private keys can be found in this article.

SSH_USER
Add another new secret and name it REMOTE_USER. The value should be the username of the site owner + the site slug. Example: flytrevan+super-fly. If the site is owned by an Organization the value should be team + the username of the Organization + the site slug. Example: team+pixel-design-studio+pie-hard. More information on identifying the username and site slug can be found here.

Test it out!

You should now have everything in place and are ready to test out your workflow! You can commit your change to your local project and push to GitHub and GitHub Actions should now trigger a build. You can watch the progress of the build on the Actions tab of your repo in GitHub. If the workflow builds successfully, you should see a green checkmark next to the most recent commit.