I recently wrote a public pod to share some common classes in my team. Since Github Actions came out I never had the chance to test them. So that was the perfect time to give it a shot.
I use them to validate that my library is compiling, that all the tests pass, that the codebase respects our coding style and that the podspec is valid.
Let’s see what are the simple steps you need to do.
Creating the pod
To create a new pod you just have to run
pod lib create MyAwesomePod. This will bootstrap a new project, with directories and placeholder classes.
Once it’s done, the first thing to do is to create a
Gemfile in the
Example folder to lock the versions of your ruby dependencies.
You also want to create a
Fastfile in the directory
Example/fastlane and add a lane to compile and run the unit tests.
Now, you can run your unit tests with a simple command:
bundle exec fastlane tests.
Linting source files
If you plan to allow other people to maintain your codebase, you may want to enforce some coding style rules. This can be easily done with Swiftlint.
First add the dependency to the
Example/Podfile like so:
Then create a
.swiftlint.yml file in the
Example folder to list all the rules you want to apply. The source files directories are
MyAwesomePodfolder for the pod source files
Example/MyAwesomePodfolder for the example source files
Finally, add a fastlane action to your
Fastfile to run
Now that we laid the groundwork, we can add the Github workflow.
.github/workflows/main.yml file with this content:
Each time you push on the repository, the workflow will:
- install ruby dependencies
- install pod dependencies
- compile the project and run the tests
- check the coding style
- validate the pod with
pod lib lint
We saw how easy it was to set up Github Actions with fastlane. With this simple workflow you can be confident that all those checks will run every time you or other contributors push to the repository.
If you are interested in all the actions available, you can find them here.