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.
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.
Here are some important things I needed to do before pursuing the Github action workflow
sudo ln -s /home/<your_non_root_user>/soupynoodles.dev /var/www/html. This establishes a symlink letting you change contents in a non-root user’s home folder and serve files from there.
/home/<your_non_root_user>/.ssh/authorized_keys. The private key-pair will be used in the workflow to allow the plugin to ssh correctly.
The rest of the workflow is very simple and you can copy over my workflow if it suits your needs.
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: CultureHQemail@example.com with: args: install - name: bundle build uses: CultureHQfirstname.lastname@example.org 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.