Before I start, I want to let you know that although I mentioned iOS App in the topic, configuring Github Action for anything else would be very similar.

What are GitHub Actions?

First, let me tell you what Github Actions are? According to Github docs “GitHub Actions enables you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository.” To put in simple words, Github Actions performs some tasks, when some action is performed. Action being Pull Request, Push, etc. And tasks being performing CI/CD or sending some notifications and/or message to someone.

In this, we are going to set up Continous Integration for your shiny new iOS project. To understand Continous Integration, you should be familiar with the Agile Development model.

Agile Development Model

Wikipedia I believe summarizes the Agile Development model very nicely “In software development, agile approaches develop requirements and solutions through the collaborative effort of self-organizing and cross-functional teams and their customer/end-user. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change.” In Agile development, software should be made in various and small modules and later integrated into the main codebase.

This integration can be done periodically or continuously. For Continuous Integration, when someone pushes a new chunk of code or creates a new pr, there will be some automated tests that will check if the new chunk will properly integrate into the project.

Just a segway here, you must have noticed I am mentioning CI/CD and wondering what is CD. CD stands for Continous Delivery. It focuses mainly on the “Early Delivery” part of Agile Development. With continuous delivery, one can deploy their applications to Testflight or even to the App Store directly if a new code is pushed to a particular branch of the project.

Configuring Github Actions

So let’s start with how are we going to configure Continous Integration. Github Actions and many other CI/CD tools use YAML to run jobs. “Jobs” refer to the task, which is to be performed. There are multiple ways to run tests and build iOS projects. I find the easiest and effective way is to use Fastlane. With Fastlane, you can also set up automated screenshots, and also CD as your project grows!

To use CI you must know how to write tests for iOS. Because without “tests”, there is no “testing”. I find this tutorial byMichael Katz on raywenderlich.comone of the best. So I would recommend before starting with CI you should check that out.

Now that all the theory is out of the way, let’s jump into the meat of the thing. For this tutorial, I am using a dummy project, with dummy tests because why not?

You should have installed Fastlane CLI on your mac. If not just simply run this command on your terminal:

brew install fastlane

Now that you have installed Fastlane, go into your project directory run

fastlane init

When you will run the above command you will see a menu like this

 

choose 4 and then press return. Fastlane will then run all the necessary configuration and bring you back to your terminal (you might need to press return for a couple of times). Now that Fastlane has been initialized, we need to configure it to test and build our app. Go into your project directory and in the Fastlane folder, open fastfile. Fastfile is the name of the configuration file of the Fastlane. After opening the file copy and paste the following code

update_fastlane

default_platform(:ios)

platform :ios do desc “Testing App” lane :tests do run_tests(workspace: “test.xcworkspace”,devices: [“iPhone 11”, “iPhone 8”],scheme: “test”) end end

The first line of code tells Fastlane to update automatically. Others define what to do when Fastlane is told to run tests. Change the test.xcworkspace to your Xcode file and scheme to your app’s scheme. You can check the scheme of your app by opening your Xcode project, under product, go into the scheme. The selected scheme will be the scheme you want to put here.

My code above tests the app on iPhone 11 and iPhone 8. You can change that by altering the names under devices. Now that the Fastlane part is ready to test some hot new apps, let’s move to set up GGithub’sactions. By the way, you can also run tests locally by running this command.

fastlane tests

To set up GitHub actions you need to create a file with extension .yml under .github/workflows. The name of the file will be the name of your action. I would recommend creating the file with vim with the following command just make sure that you are in your project directory on the terminal.

vim .github/workflows/CI.yml

Now add the following code to configure your Github action.

name: CI on: push: branches-ignore:

• master pull_request: branches:
  • master
  • develop jobs: test: runs-on: macOS-latest steps:
  • uses: actions/checkout@master
  • name: Installing Cocoapods run: | pod install pod update
  • name: Running Tests run: bundle exec fastlane tests

The above code will create a GitHub Action that will first install all the necessary pods and then will test the app. The above code will run on the push to every branch except master and pull request to branches master and develop.

Our action will run on macOS. The first job performed is getting the project repo to your machine. Then it will install and update all the Cocoapods. After that our project will be ready for testing. It will be performed by the last command, building the project, and running all the tests. Your GitHub action should be triggered whenever you push to any branch except master and on pull requests on master and develop.

The last step left is to push your project to Github. And your project is all set.

One of the reasons I decided to write this article was because when I was trying to set up my project for Continous Integration, it took my a while to figure it out but when I did I was surprised how easy it was! Hope your project is all set with Continous Integration. If any of you get stuck with do reach out!