A CI Praxis — Exploring Continuous Integration Via Github Actions

As full-stack developer in-training, I have found using Github as a medium for code management to be seamless and coherent in many instances, and maddening in others. I certainly recognize its utility in working on group projects, and I appreciate all of the Git-related features that are found in VS Code, my current code editor of choice. Yet I will be the first to admit that I have accidentally merged, overwritten, and lost code numerous times, particularly when I first started using the Git ecosystem. Therefore I must also reveal that I was initially reluctant to approach the topic of continuous integration, until it became absolutely necessary for me to incorporate the practice into my developer education. However, I found the topic to be interesting, and not as daunting as I anticipated. What follows is my exploration of continuous integration and continuous delivery using Github Actions, and what developers who are new to the subject are to expect.

CI/CD/CCO/XP/Many/Other/Practices/Known/By/Short/Acronyms

Before we tackle Github Actions and its usefulness in software development, it is worth mentioning a few other concepts which fall under the same umbrella as continuous integration, that being general software engineering practices. A practice in this respect is any set of guidelines which attempt to organize and streamline the process of software development, from the initial generation of ideas, to the finished product, which would typically in our case be a working full-stack application deployed for use by the public.

Github Actions For CI Execution

Now that some overview has been established as to software engineering practices, we may examine how to undertake a CI process. This is where Github Actions comes in. It is a service which uses the CI/CD pipeline to automate the software workflow. Since Github itself is already such a well used medium for version control and project collaboration, this is an ideal choice for CI goals.

  • Event — specific activity which triggers a workflow. Activities such as pushing commits to a repository or issuing a pull request can function as events which may be tied to a given workflow.
  • Job — A set of steps which operate on the same runner (see below). Jobs may run in parallel, or sequentially, as specified.
  • Step — An individual task which may run commands from within a job. Steps may either be actions or shell commands, and must execute on the same runner, allowing data share between actions.
  • Runner — A server, which operates on the Github Actions runner application. These may be hosted by Github or on developer’s own environment. Runners listen for jobs, and execute one at a time, reporting metadata in the process.
  • Actions — The most atomized portion of the workflow, actions are the actual commands which form steps, which in turn form a job. The Github community has already created actions, but custom ones may be defined as well. Actions must be included with a step to be used in a workflow.

Analysis of A Workflow

GitHub Actions uses YAML syntax to define the events, jobs, and steps. These YAML files are stored in your code repository, in a directory called .github/workflows.

  1. In the .github/workflows/ directory, create a new file called learn-github-actions.yml and add the following code.