Linode, HTTP/HTTPS & Deployment Part 2 | /var/log/share

Linode, HTTP/HTTPS & Deployment Part 2

In my earlier post, I said I would go about testing Github actions as opposed to my custom deploy script I shared earlier. After diving into GitHub actions, I found that this was indeed easy to do. Github’s actions enable you to run custom actions when you push changes to your repository. Think of continuous integration pipelines but all done through Github. So, taking a look back at the deploy script from the earlier post, I mainly need a way to run bundle to install Jekyll and build the website. Once, the site has been built - I need to SCP the contents into Linode machine spun up earlier.

Finding the right Github Actions

Github marketplace has a catalog of all actions available to use. Before, selecting the ones you want - take a look at the source repository so no malicious code is present. Github’s actions are fairly new and one of the actions for this job involves SSH. So, you want to ensure the actions don’t have any backdoor to capture the information you enter. Initially, I pondered using this guide here to build an action but I found some plugins fit my use-case correctly.

Prerequisite

Here are some important things I needed to do before pursuing the Github action workflow

The rest of the workflow is very simple and you can copy over my workflow if it suits your needs.

Github Action Setup

Fairly simple - all you need is a file in your repository .github/workflows/main.yml. This workflow will be executed every time you push to master.

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request 
# events but only for the master branch
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@v2
    
    - name: bundle install
      uses: CultureHQ/actions-bundler@v1.0.0
      with:
        args: install
    
    - name: bundle build
      uses: CultureHQ/actions-bundler@v1.0.0
      with:
        args: exec jekyll build
    
    - name: tar site
      run: |
        tar czf site.tar.gz _site/
    
    - name: clear deployment artifacts
      uses: JimCronqvist/action-ssh@master
      with:
        hosts: $
        privateKey: $
        command: |
          rm -rf _site/ soupynoodles.dev/;
          rm site.tar.gz untar.log;

    - name: transfer tar ball
      uses: lbejiuk/scp_action@v1
      with:
        public_key: $
        ssh_port: 22
        ssh_username: $
        ssh_host: $
        source: 'site.tar.gz'
        target: $
    
    - name: check if tarball exists
      uses: JimCronqvist/action-ssh@master
      with:
        hosts: $
        privateKey: $
        command: test -f site.tar.gz && exit $?

    - name: untar website and copy over artifacts
      uses: JimCronqvist/action-ssh@master
      with:
        hosts: $
        privateKey: $
        command: |
          tar xvf site.tar.gz > untar.log && echo done;
          mv _site/ soupynoodles.dev/;
          mkdir soupynoodles.dev/log/;
          chmod 755 soupynoodles.dev/;

I used some third party plugins here:

Github’s actions are great and it’s pretty solid that you can now build these workflows for free in Github itself. The only bits I feel I want to improve right now is setting up my Linode machine itself. I’m contemplating running a puppet master-slave configuration with a nano instance serving as the master. I won’t do it unless I see the need for it. That’s all from this post! hope y’all liked it.