The Goal

Ultimately, to improve workflow when working on Neto sites.

The main goals are:

• Create a staging version of the current Neto theme.
• Easily deploy both the staging and production themes via the command line. Allows devs and clients to easily view the staging version of the site theme.
• Implement Git for sub-versioning.

The workflow we're creating:

1. Developer creates new staging branch against master. Does coding work, pushes staging branch to Github and Github Actions deploys to staging theme on Neto's server.
2. Client/Stakeholders test on staging theme (in Neto's case by just adding ?nview=my-theme-stg to the site URL).
3. Once work is approved, developer merges stage to master. Github Actions automatically deploys changes to the live theme.

Setting up Github Actions

We need 2 Github Action files, One for deploying to production, one for deploying to staging.

Step 1: Create the .yml files

Locally, in your repo create 2 new .yml files (and folder structure if needed): .github/workflows/main.yml and .github/workflows/stg.workflow.yml. These will house the code for our Github action.

On the main.yml file

We're going to use this Action: FTP Deploy. To use, simply paste in the following code into your main.yml file:

on:
  push:
    branches:
      - master
name: Publish Website
jobs:
  FTP-Deploy-Action:
    name: FTP-Deploy-Action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2.1.0
      with:
        fetch-depth: 2
    - name: FTP-Deploy-Action
      uses: SamKirkland/FTP-Deploy-Action@3.1.1
      with:
        ftp-server: sftp://sftp.neto.com.au:1022/httpdocs/assets/themes/my-theme
        ftp-username: ${{ secrets.FTP_USERNAME }}
        ftp-password: ${{ secrets.FTP_PASSWORD }}
        local-dir: src/
        git-ftp-args: --insecure

So, a few things to note:

The lines:

on:
  push:
    branches:
      - master

Tell Github when the jobs: below are to be run. In this case the jobs will run when there is a push to the repo's master branch.

The next section of the above code is the job FTP-Deploy-Action. For Neto (and indeed most other FTP applications) this can remain the same. You will, however, need to update a few small things:

ftp-server: sftp://sftp.neto.com.au:1022/httpdocs/assets/themes/my-theme/

Not only does this line refer to the server name, but also the transfer protocol (sftp://), the port number (:1022) and the location directory (/httpdocs/assets/themes/). For Neto you might just need to change the location directory path.

local-dir: src/

This obviously refers to the local directory. In my case, I've got a bunch of things in the route of my repo and only want to deploy the stuff in the src directory.

On the stg.workflow.yml file

Copy the above main.yml file's contents into stg.workflow.yml to create an Actions file for staging deployment. We're going to change 2 things:

Change when the job runs to when we push to the stage branch:

on:
  push:
    branches:
      - stage

And change the destination directory to your staging theme:

ftp-server: sftp://sftp.neto.com.au:1022/httpdocs/assets/themes/my-theme-stg

Push these files up to your remote repo.

As for ftp-password and ftp-username, we'll deal with those in the next step.

Step 2: Set up Secrets in Github to store our FTP login and passwords

Secrets allow you to store sensitive information like usernames and passwords for, say, your FTP account. To add them go to your repo's Settings page, then Secrets tab. Simply hit New Secret at the top right of the page, give it a name (eg: FTP_USERNAME) and a value. Note, only 1 name and value pair per Secret.

Step 3: Testing

I simply created a dummy test.txt file in my src/ directory and pushed it to master. You can see the Action run your repo's Action tab. Click the Action's name to see the live log. For a sanity check, I just used Filezilla to confirm this new test.txt file appeared on the remote server.

I repeated the exact same test for the stage branch.

The first time you run FTP Deploy it may take 1 or 2 minutes to index everything.

Note that merging stage to master will also trigger a deploy to master.

Additional stuff (optional)

Since pushing to master now deploys to the live server we might want a way to confirm that's what the developer actually wants to do (don't want to deploy by accident).

We can add the Protected Branches script below which will ask the user to confirm if they want to deploy. This lives in the .git/hooks/pre-push file.

Are you sure you want to push to master? (y/n):

BRANCH=`git rev-parse --abbrev-ref HEAD`
PROTECTED_BRANCHES="^(master|dev|release-*|patch-*)"

if [[ "$BRANCH" =~ $PROTECTED_BRANCHES ]]; then
  read -p "Are you sure you want to push to \"$BRANCH\" ? (y/n): " -n 1 -r < /dev/tty
  echo
  if [[ $REPLY =~ ^[Yy]$ ]]; then
    exit 0
  fi
  echo "Push aborted."
  exit 1
fi
exit 0