Github Actions is the new kid around the block for workflow automation. DevOps guys are having the day for it, as it makes a heck of a lot easier for them to implement CI/CD 🔥 from the same place they host their project.
Last month, I worked on setting up a workflow for building a deployment pipeline. The project that I’m part of, is a desktop application 🖥 built on Electron.
You might be thinking 🤔, why build a desktop app on Github’s Actions? Because the build process is quite cumbersome and take a pretty big chunk of the developers precious time 😒. As we were already planning to build a CI/CD pipeline, we thought to give it a try with Github Actions 😁 (as we already host our project on Github privately).
Disclaimer: This post applies to Github’s Linux and Windows runners, as I have tested on those. Although Mac OS runner isn’t much different then the Linux runner. You can find more about them HERE.
Testing the workflow locally
When I'm trying out something new 🐱🏍, the first thing I try is to set up a local environment to test it out 🧗♂️. Can it be done for Github Actions? The answer is not definitive 🤔. We can use our own Docker Image as a custom runner, and test it locally on that local Docker Image. We can’t create the exact environment to mock the workflow, at least I couldn’t find any solution.
Complex processes
Setting up a YAML configuration for projects that already use some kind of framework, or has a rich set of build tools is really easy ✌. But when we are writing configuration for an application where the build 🏭 requires multiple process, with sources from different languages and frameworks, it kinda becomes messy to keep track of the process flow. Sure you can divide the processes into “Jobs” but that has its own pitfall 👎, which I’ll talk about later in this post.
Actions from Marketplace
On the Github Marketplace, there are quite a lot of actions written by other developers 👩💻. These actions can be written in two ways, using Docker configuration or using JavaScript. While JavaScript actions run on all platforms, actions written in Docker configuration can only run on Linux. So, we might find some action that cuts down your task into half, but still can’t use it, only because we are using Non-Linux runner.
Data persistence on a workflow
In a complex build 🏭 process, you may want to pass some information from one job to another, to build a flow. The only way to pass data in-between jobs, is to use Github Artifacts. They aren’t cheap either. You can’t delete an artifact manually 😲. GitHub stores artifacts for 90 days for pushes and pull requests. Storing artifacts uses storage space on GitHub. Also, for private repositories like ours, there is a fixed amount of “Free Minutes” and “Storage” after which it will start billing 💵. One good thing is that files uploaded as artifacts are compressed as “zip”. So, if you are uploading log files or reports, you may not need to think about the storage, at least 😌.
Limited flexibility for Actions
One particular problem I faced 🤨 while using an action from marketplace is that, we can’t set working-directory when executing them. That means, those actions must always be executed from the root directory 😬. This won’t matter if we are building a single project. But if it’s a monorepo, then the actions won’t work if it doesn’t accept the directory path as parameter. In my case, the action accepted a directory path, so I was saved somehow 😌.
That’s it for today folks. See you, when I see you 🐱👤.
Cover Image Credit: kaleidico
Top comments (2)
I've had some quite good results with Github Actions. Then again I'm not doing anything crazy complicated at the moment anyway.
I'm not aware of any way of realistically testing a build process. Have you done something in the past that would be worth sharing? As you say though with Container based CI you can wrap the container and test the internal logic.
The project that I talked about, is proprietary, that's why I couldn't share any of the code. Thing that I did in the past were very simple, so I don't think they will be worth your time.
What I meant by test is that, Github has detailed documentation on their system specification and environment of the runners. So, we could recreate the same setup on a Docker for testing. Alternatively, we could run create a custom Docker image and write the build process with Gulp/Grunt or some other libraries. But I haven't tried it myself.