Why is SwiftCurrent using GitHub Actions?
It’s the best choice for the project.
When building out the CI/CD pipeline for SwiftCurrent, we decided to use GitHub Actions. This article will list out the pros, cons, and our final assessment so that others can build off of our analysis. Hopefully, this will act as a decision log for the community if the need arises to change the pipeline.
Start with the positives.
Codified like any great CI/CD
The best pipelines allow you to commit themselves into source control with the rest of your source code and tests. Saving our pipeline to source control helps us treat our pipeline with the same importance as our tests.
With GitHub Actions, we can write out our pipeline in YAML and track changes in source control. Also, because the YAML must reference Secrets configured for the pipeline, we have clues for the remaining configuration required to rebuild the pipeline.
Transfers with the repository
This positive was essential to us. Whoever forks our repo will automatically get our pipeline in the new fork, allowing that fork to: run tests immediately, validate the packages, and lint the project. Certain aspects of the pipeline are restricted to our repository when dealing with releasing and other steps that require one of our Secrets. Still, most of our pipeline is there to help others who want to build on the project. Even better is that others can quickly reconfigure the root pipeline to run on their fork with GitHub Secrets.
Fast enough for our work
Our pipeline currently (at the time of writing this) takes ~8.5 minutes to complete when validating a PR and ~24 minutes between merging a PR to release and update the documentation. While faster and valuable feedback is always the goal, these speeds are fast enough for the community’s current level of patience.
Scales as needed
Different from the speed of the pipeline is parallelization and the load the pipeline can handle. As the community grows, we expect more and more commits and an ever-increasing number of builds for the project. We don’t want community members waiting an hour for their turn to build their commit to get their feedback. We want fast feedback. The speed of the pipeline is important, but not waiting to start the pipeline is just as important.
Endless support
GitHub Actions is part of the open-source community, and it has already garnered an enormous amount of support from the community. There is either native support, a community-built action, or an action endorsed by GitHub for several jobs that we have wanted to do. There are, however, several jobs we were unable to find existing actions to use. For these, we tried to consolidate to Fastlane and then shell scripts. Even with those modifications, we are still left with a small, understandable, and easy-to-manage pipeline.
Keeps cost low
There are three elements to this positive: the cost of ownership, the cost of running, and the cost of maintaining. All of these costs are near zero for SwiftCurrent.
GitHub Actions is free for public repositories, and Microsoft hosts them. This means that the only upkeep we incur is configuring for custom software that is not on by default. At the time of writing, that means installing Jazzy and SourceKitten during doc generation. The second level of maintenance is managing the Xcode and OS version, which can usually be defaulted to “macos-latest” but is not always the case (see negatives.)
What about the negatives?
Slow to adopt Big Sur
It has taken Microsoft nearly a year to point “macos-latest” at Big Sur. This rollout has been painfully slow and, at one point, was locked down to limited beta testers. This forced the project to continue to deal with Xcode 12.4 build issues and prevented the project from adopting newer features in Swift 5.5. Now that Microsoft is rolling out Big Sur to the masses, we have updated our pipeline, but questions remain if this will be the norm for each major release going forward.
No ARM architecture for building
Microsoft build boxes are nice (see their specs here.) But one configuration is missing: M1. Microsoft does not offer M1 build boxes, meaning that the pipeline cannot capture complications due to compiling or developing on an ARM processor. At first, this may not seem like an issue, but when one of the community members adopted an M1 laptop, they were immediately met with problems running the test suite. These issues were resolved, but the fact stands that the pipeline cannot provide this feedback.
Fast enough but not Fast
While the pipeline is currently fast enough to meet the acceptable speed threshold, it is not the fastest pipeline we could have. When running the pipeline locally, you’ll find that most newer computers can complete faster (about half the time). A dedicated build box would be faster in the daily runnings, but not necessarily the overall maintenance time.
Making reusable custom actions
Making custom actions is both a strength and weakness for GitHub Actions. Specifically, when you create one, you must publish it for all to use. This requirement has held SwiftCurrent from contributing new actions as ours wouldn’t make sense to the larger community. Currently, we have code duplication of our pipeline between the CI pipeline and the PR pipeline. This code duplication would not make sense as a general action for the larger GitHub community. For now, we will continue with the code duplication, and at some point, we may find helpful actions to create for the community.
Final Assessment
With all this written out, hopefully, it is clear why SwiftCurrent is using GitHub Actions. The first three positives are vital because they relate to the community engaging and benefiting from the pipeline. If the time comes for reassessing the pipeline, I hope this article helps with that decision.
