Github introduced CI and CD based on actions. It allows you to automate how you analyse, build, test and deploy your projects on any platform, including Linux, macOS and Windows.
I was excited over this news and can’t wait to try it out. My idea was to automate building and unit testing of Swift projects.
There are two types of actions and we should know the difference before starting.
Docker container vs JS
Lights! Camera! Github Action!
As an example I will use Texstyle. It’s a framework for formatting attributed strings. Let’s start with a complete configuration and inspect it step by step:
At first you should select an event to trigger the workflow. My workflow is triggered on any pull request in the repository. Optionally you can label the workflow with
Workflows must contain at least one job. My workflow contains only one job for testing. It is possible to run up to 20 jobs concurrently per repository across all workflows.
Jobs run on virtual host machines that are specified with
runs-on. In my case it’s
macOS-latest, because I want to use xcodebuild. It’s a standard Apple developer tool and works on macOS only.
Texstyle supports both iOS and tvOS, so I want to run xcodebuild with two destinations. To specify different variations, I used
strategy.matrix. I added two simulators with actual OS versions.
And the last step is to adding steps 🙃. I used
checkout action to access the contents of the repository. You can specify the version of actions after @ sign with a release version, branch or specific commit.
Everything is ready for testing. I added
run with bash commands to change current directory, run xcodebuild and send code coverage data to Codecov. To use matrix variables, I added
env with the required variable name.
To read more about workflow syntax, check the documentation.
Comparing to Travis CI, my configuration looked like:
That’s it! Here is an example of live logs:
But that’s not the end, it’s just the beginning! Suppose that we want to reject pull requests if there are any linting warnings or errors. The most popular lint tool for Swift is Swiftlint. For now it’s possible to run it and see warnings in logs that is not enough. It would be great to see annotations from SwiftLint Violations via GitHub Checks API, or even have suggested changes. And actions allow to use this API easily.
As for me Github Actions CI is a game changer. It is deeply integrated into the service. And community-driven actions allow to reuse common scenarios.
Let’s summarise my experience with pros and cons.
- Various triggers for workflows. Pull requests, staring repos, project card statuses, scheduled events etc.
- Speed. According to logs for Texstyle, last builds were 2 min 12 sec on Travis CI and 1 min 8 sec on Github CI.
- Preinstalled software. macOS images have fastlane, swiftlint, Cocoapods, Carthage etc.
- Marketplace. There are plenty of actions developed by community. You can reuse any of them.
- Pricing. Of course, it’s free for open source. The time limits look pretty good — 2000 minutes for free plan and 3000 minutes with a Pro plan including private repositories 😏.
- Still in beta. First actions were written in HCL syntax. Support for it will be removed on September 30. And maybe it’s not the end, YAML syntax may be updated as well. So be ready to migrate your actions before public release.
- Debugging. It’s hard to debug workflows as any CI service. You must trigger related event and wait for all steps. It’s not possible to test it locally, even validate workflow syntax.
- Documentation. On of the goals of this article is to clarify Actions benefit for myself and give it a try on real project. I had many unobvious errors, official documentation and StackOverflow won’t help. For instance, a multiline
runcommand won’t work without a
namelabel. I believe open source workflows will help to avoid dump errors and handle edge cases in the future.
Thanks for reading! If you have any questions or ideas of workflows, feel free to leave comments or ping me on Twitter @iosartem.