Nerd For Tech
Published in

Nerd For Tech

Let’s talk automation

Setting up Continuous Integration with GitHub Actions — Part 1

What is CI/CD?

Continuous Integration and Continuous Delivery, or CI/CD, is the term given to the process of automatically building a project and deploying it out to delivery channels like itch.io, the android store, or the iOS store every time code is successfully merged into a specific branch or branches in source control, or based on certain conditions like firing off a publish from GitHub (or the equivalent in other source control providers). This process is typically implemented in Team based software engineering efforts and can help in verifying that code being merged from several developers into a single source is stable and can be released to users. This process can, and often does, include automatically running unit tests against code as well as producing a build of the code and a release. Logically, at a high level, we can split the process into 2 parts, consisting of Continuous Integration and Continuous Delivery. We are going to take a look at The first part, Continuous Integration, in this article and save Continuous Delivery for future articles.

Continuous Integration and Delivery (image credit to automated-360.com)
Continuous Integration and Delivery (image credit to automated–360.com)

Making a CI choice

There are numerous systems and software packages that facilitate implementing Continuous Integration. Jenkins, TravisCI, CircleCI, and GitHub Actions are a few of the many options available and each of these options has pros and cons depending on the team's workflow, the source control provider chosen, and the infrastructure in place. For our purposes we are building Unity projects, storing them in GitHub, and not hosting or utilizing other infrastructure tools like Team City, or Azure DevOps. The plan is also to deploy our projects to a number of hosting services including, itch.io and GitHub Pages. When looking at our project parameters GitHub Actions stands out as a strong contender as it is already integrated with our source control provider and will allow us to meet our other goals, with the help of some Actions provided by members of the community.

Github Actions

GitHub Actions are GitHub’s event-driven platform for providing the ability to run pieces of functionality like running unit tests and providing the automatic building of our projects in response to events like checking in code to a specific branch. The entry point for our work is a Workflow file. Workflows contain Jobs that contain Steps that are the list of actions to be run on virtualized environments to provide us with our functionality.

Workflow structure from Githubs documentation at https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions
Workflow structure from GitHub’s documentation at https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions

GitHub Secrets

As a best practice, we don’t want to store access tokens or usernames and passwords alongside our code in our GitHub repo because that will make them available to others and expose us to potential malicious actions. GitHub provides us the ability to store those pieces of information as, what they call, Secrets. We will be storing access information for our Unity license, and access credentials for sites like itch.io when we get to deployment.

Overview of steps to implement our CI workflow

There will be a number of steps to our implementation of CI and so it would be a good idea to list them here.

  1. Create Workflow folder and files
  2. Obtain a Personal License file for Unity (to be used for the virtualized instance of Unity on our GitHub runners)
  3. Store That Unity License as a GitHub Secret
  4. Create a GitHub access token for use with calling GitHub provided actions to upload and download files generated during a build
  5. Store the GitHub token as a Secret
  6. Configure our workflow

Our last step is then broken down further as follows:

  1. Grab our code from our repo
  2. Run a cache step to optimize future runs
  3. Build our project on a GitHub runner configured to run Unity
  4. Upload the results of that build step so that they are available for future steps in Continuous Delivery and for us to download.

If we had unit tests to run, which we don’t have at this time we would include running those tests before our build step to ensure that we only do a build if they pass.

Next Time!

We’ve covered a lot of ground in learning about CI/CD and how we plan to implement it in this article. Next time we’ll go over the actual implementation of the Integration half of our CI pipeline. If you enjoyed this article, or want to come along with me as I progress on my journey, follow me at gamedevchris.medium.com.

--

--

--

NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit https://www.nerdfortech.org/.

Recommended from Medium

Epacris — The List Methods in Python

How to build a WordPress mobile app?

Debugging NodeJS within a Docker Container on VSCode

Getting setup for WordPress Gutenberg accessibility testing

When the BASH Ain’t Got *Flash* — Beautify the CLI

terminal without styling

Loading Data in Snowflake

Week 3: Polyglot Programming

Global Interpreter Lock(GIL):

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christopher West

Christopher West

Unity Game Developer, Software Engineer, Gamer, Musician, and Father. Christopher is a creative that enjoys a challenge and loves coding.

More from Medium

How to Set Up a Simple Drop-Loot System in Unity

Initializing A Git Repository in Unity

Trigger collisions

Creating Rewarded Video Ads in Unity