Improving Neto development workflow with Github's Actions
Tags: neto, github, git, workflow
Published: 2020-09-08 23:34:29

# 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](https://github.com/marketplace/actions/ftp-deploy). To use, simply paste in the following code into your `main.yml` file:

```yml
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:

```yml
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:

```yml
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):`

```bash
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
```