How I Utilized GitHub Actions in My Workflow

Aaro Alhainen
The Startup
Published in
4 min readSep 24, 2020



I have known GitHub Actions since they were released to the public but I hadn’t any good use case available until now. Recently I rewrote my portfolio site and built it with Sapper instead of Nuxt.js. Also with the refactoring, I planned to add some kind of blog section or page where I could publish some of my thoughts and ideas. The learning curve to use Sapper was so short that it led me to think that the writing process of blog posts must be as simple as possible too.

Previously if there were any need for modifications for the site I needed to clone the repository, install all npm packages, hope that everything worked still, realize that hoping was not enough, and fix every issue that was caused by rapidly developing npm dependencies and only after that I was able to do the actual modifications. Yay!🎉 After the modifications, there was the building process and committing and pushing the built page to the GitHub and then the thing was done and for this, I needed a real computer.

So what would I simplify? I wanted to get rid of the fact that I would need the full development environment installed and running to make some simple modifications(change a year or fix a typo) or publish a blog post and also I wanted to be able to do these things even with my phone in a local coffee house. Also, this would solve the issue that whether the machine would be running Linux, Windows, or Mac, there wouldn’t be any compatibility issues with any dependencies since the actual building process was done always in the same controlled environment.

Now the problem is introduced so what is the solution? GITHUB ACTIONS! With GitHub Actions you can automate quite a much in your workflow. I utilized them to automate the building process and bound it to the push event. So every time I push to the repository, the automation will kick in.

How did I do it:

  1. I read these two good documentations from GitHub and The first one goes through using the GitHub Actions in general and the second one goes more specific to use them with node.js and this leads us pretty close since the node.js workflow template fits quite well.
  2. I modified the node.js workflow template by specifying it to use only one node.js version and adding a couple of new lines. The final YAML file is under:
# This workflow will do a clean install of node dependencies, build the source code and run tests across different versions of node
# For more information see:
name: Node.js CIon:
branches: [ master ]
runs-on: ubuntu-lateststrategy:
node-version: [12.x]
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
node-version: ${{ matrix.node-version }}
- run: npm install
- run: npm run export --if-present
- run: git add .
- run: git config --global 'Aaro Alhainen'
- run: git config --global ''
- run: git commit -m "Automatic build commit"
- run: git push

I changed the “node-version” to be only 12.x and added all run lines at the end of the file. All of them besides the npm run export is pretty self-explanatory. The line “npm run export” is Sapper specific and it basically generates a static version of the site.

This config is set so that the job will be run on each push to master branch to make the build. You can also define the action hook to be an example ”release” if you want.

After this, the workflow itself is working 🎉

The build is being processed
Build succeeded

But in this case, it was not enough. I needed to modify also the package.json “export” command a little.

The original command was like this:

"export": "sapper export",

After modification it looks like this:

"export": "sapper export && rm -r ./docs && mv ./__sapper__/export ./docs",

This was needed since the export command builds the site under “__sapper__” directory which is gitignored by default so we need to move the build out of there. Another reason is that GitHub pages work only in root and docs directories so we would have to move the files anyways. Also, every time before moving the files we need to clear the destination directory so we can be sure that there is not some old stuff left hanging.

Now I can make any changes or even make full blog posts through the GitHub website’s editor with an iPad and keep my site updated. This was just a first step in GitHub Actions and I’m planning to extend them to run tests also.

Here I presented how easy it is to start using GitHub Actions in a project. Hopefully, this helped and maybe inspired you also to try the GitHub Actions and since they are free to use with pretty high limits there is no reason why not 😁



Aaro Alhainen
The Startup

Software Developer and CS student >